Processor, machine-readable medium, method, processing system, and apparatus for instructions and logic for providing general-purpose GF(256) SIMD cryptographic arithmetic functionality

Abstract

Processor that includes: a decode stage (440) for decoding a first instruction for a multiplicative one-instruction-multiple-data inverse function, SIMD inverse function, for a binary finite field, the first instruction specifying a source data operand set and a normalized irreducible polynomial; and one or more execution units (460) responsive to the decoded first instruction to: to calculate a multiplicative SIMD inverse function for a binary finite field modulo the irreducible polynomial for each element of the source data operand set; and to store a result of the first instruction in a SIMD destination register (458).

Description

AREA OF REVELATION

[0001] The present disclosure relates to a processor, machine-readable medium, method, processing system, and apparatus for instructions and logic for providing general-purpose GF(256) SIMD cryptographic arithmetic functionality. BACKGROUND OF REVELATION

[0002] Cryptology is a tool that relies on an algorithm and a key to protect information. The algorithm is a complex mathematical algorithm, and the key is a sequence of bits. There are two basic types of cryptographic systems: secret-key systems and public-key systems. A secret-key system, also called a symmetric system, has a single key ("secret key") shared by two or more parties. This single key is used for both encrypting and decrypting information.

[0003] For example, the Advanced Encryption Standard (AES), also known as Rijndael, is a block cipher developed by two Belgian cryptologists, Joan Daemen and Vincent Rijmen, and used by the United States government as an encryption standard. AES was announced on November 26, 2001, by the National Institute of Standards and Technology (NIST) as US FIPS PUB 197 (FIPS 197).

[0004] AES has a fixed block size of 128 bits and a key size of 128, 192, or 256 bits. Key expansion using the Rijndael key table transforms the 128-, 192-, or 256-bit keys into 10, 12, or 14 round keys of 128 bits. The round keys are used to process plaintext data in rounds as 128-bit blocks (considered as 4-by-4 matrices of bytes) and convert them into ciphertext blocks. Typically, for a 128-bit input to the round (16 bytes), each byte is replaced by another byte according to a lookup table called an S-box. This block cipher section is called subbytes. Next, the byte rows (considered as a 4-by-4 array) are cyclically shifted or rotated to the left by a specific offset (i.e., row zero by 0 bytes, row 1 by 1 byte, row 2 by 2 bytes, and row 3 by 3 bytes).This section of the block cipher is called row shifting. Then, each of the byte columns is represented as four coefficients of a polynomial in a finite field, GF(256) (also called a Galois field of 2). 8 ) and multiplied by an invertible linear transformation. This section of the block cipher is called column shuffling. Finally, the 128-bit block is XORed with a round key to produce a 16-byte ciphertext block, which is called round key addition.

[0005] On systems with 32-bit or larger words, it is possible to implement AES encryption by implementing the subbyte, row shift, and column merge transformations in four 32-bit tables with 256 entries, using 4096 bytes of memory. One drawback for a software implementation is performance. Software runs orders of magnitude slower than dedicated hardware, so it is desirable to have the added performance of a hardware / firmware implementation.

[0006] Typical straightforward hardware implementations that use lookup memories, truth tables, binary decision trees, or 256-input multiplexers are expensive in terms of circuit area. Alternative approaches that use finite fields isomorphic to GF(256) can be efficient in terms of area, but they can also be slower than the straightforward hardware implementations.

[0007] Modern processors often contain instructions to provide operations that are computationally intensive, yet offer a high degree of data parallelism, which can be harnessed through efficient implementations using various data storage devices, such as single-instruction multiple-data (SIMD) vector registers. The central processing unit (CPU) can then provide parallel hardware to support the processing of vectors. A vector is a data structure that contains a number of consecutive data elements. A vector register of size M (where M equals 2 kis, e.g., 256, 128, 64, 32, ..., 4, or 2) can contain N vector elements of size O, where N = M / O. For example, a 64-byte vector register can be divided into (a) 64 vector elements, each element containing a data unit occupying 1 byte, (b) 32 vector elements containing data units each occupying 2 bytes (or a "word"), (c) 16 vector elements to hold data units each occupying 4 bytes (or a "doubleword"), or (d) 8 vector elements to hold data units occupying 8 bytes (or a "quadword"). The nature of parallelism in SIMD vector registers could be well suited to handling secure hash algorithms.

[0008] Other similar encryption algorithms may also be of interest. For example, the Rijndael specification specifies various block and key sizes, which can be any multiple of 32 bits, with both a minimum of 128 and a maximum of 256 bits. Another example is SMS4, a block cipher used in the Chinese national standard for wireless LAN WAPI (Wired Authentication and Privacy Infrastructure). It also processes the plaintext data in rounds (i.e., 32) as 128-bit blocks in GF(256), but performs reductions modulo a different polynomial.

[0009] To date, options for efficient space-time design balancing and potential solutions to such complexities, performance-limiting issues, and other bottlenecks have not been fully explored.

[0010] US 2010 / 0 195 820 A1 describes the encryption of information, which involves the execution of a first instruction and a second instruction in a processor. The first instruction causes the processor to perform an AddRoundKey transformation followed by a ShiftRows transformation. The second instruction causes the processor to perform a ShiftRows transformation followed by a MixColumns transformation. These instructions are useful for performing AES encryption. The first and second instructions also have inverse modes that can be used to perform AES decryption.

[0011] It is the object of the invention to provide a multiplicative SIMD inverse function that performs multiple inverse calculations simultaneously in one SIMD instruction set.

[0012] The object is achieved by the subject matter of the independent claims. Embodiments of the invention are specified in the subclaims. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] The present invention is illustrated by examples. Fig. 1A is a block diagram of one embodiment of a system that executes instructions to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 1B is a block diagram of another embodiment of a system that executes instructions to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 1C is a block diagram of another embodiment of a system that executes instructions to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig.2 is a block diagram of one embodiment of a processor that executes instructions to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 3A illustrates packet data types according to one embodiment. Fig. 3B illustrates packet data types according to one embodiment. Fig. 3C illustrates packet data types according to one embodiment. Fig. 3D illustrates an instruction encoding to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality according to one embodiment. Fig. 3E illustrates an instruction encoding to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality according to another embodiment. Fig. 3F illustrates an instruction encoding to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality according to another embodiment. Fig.3G illustrates an instruction encoding to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality according to another embodiment. Fig. 3H illustrates an instruction encoding to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality according to another embodiment. Fig. 4A illustrates elements of one embodiment of a processor microarchitecture for executing instructions that provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 4B illustrates elements of another embodiment of a processor microarchitecture for executing instructions that provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 5 is a block diagram of one embodiment of a processor to execute instructions providing general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig.6 is a block diagram of one embodiment of a computer system for executing instructions that provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 7 is a block diagram of another embodiment of a computer system for executing instructions that provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 8 is a block diagram of another embodiment of a computer system for executing instructions that provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 9 is a block diagram of one embodiment of a system-on-chip for executing instructions that provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 10 is a block diagram of one embodiment of a processor to execute instructions providing general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 11 is a block diagram of one embodiment of an IP core development system providing general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 12 illustrates one embodiment of an architectural emulation system that provides general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 13 illustrates one embodiment of a system for translating instructions that provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 14 illustrates a flowchart for one embodiment of a process for efficiently implementing the Advanced Encryption Standard (AES) encryption / decryption standard. Fig.15 illustrates a flowchart for one embodiment of a process for efficiently implementing a multiplicative inverse function of an AES-S-box. Fig. 16A illustrates a diagram for one embodiment of an apparatus for executing an affine mapping instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 16B illustrates a diagram for one embodiment of an apparatus for executing an affine inversion instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 16C illustrates a diagram for an alternative embodiment of an apparatus for executing an inverse affine instruction to compute a multiplicative inverse followed by an affine transformation of the result to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig.17A illustrates a diagram for one embodiment of an apparatus for executing a finite field multiplicative inverse function instruction to provide general purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 17B illustrates a diagram for an alternative embodiment of an apparatus for executing a finite field multiplicative inverse function instruction to provide general purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 17C illustrates a diagram for another alternative embodiment of an apparatus for executing a finite field multiplicative inverse function instruction to provide general purpose GF(256) SIMD cryptographic arithmetic functionality. Fig.18A illustrates a diagram for one embodiment of an apparatus for executing a special modulo reduction instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 18B illustrates a diagram for an alternative embodiment of an apparatus for executing a special modulo reduction instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. Figure 18C illustrates a diagram for another alternative embodiment of an apparatus for executing a special AES counter mode (GCM) modulo reduction instruction to generate general-purpose cryptographic GF(2 128 )-SIMD arithmetic functionality. Fig. 18D illustrates a diagram for one embodiment of an apparatus for executing a modulo reduction instruction to provide general-purpose GF(2') SIMD cryptographic arithmetic functionality. Fig. 19A illustrates a diagram for one embodiment of an apparatus for executing a binary finite field multiplication instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 19B illustrates a diagram for an alternative embodiment of an apparatus for executing a binary finite field multiplication instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 20A illustrates a diagram for one embodiment of a process for executing an affine mapping instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig.20B illustrates a diagram for one embodiment of a process for executing a finite field multiplicative inverse function instruction to provide general purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 20C illustrates a diagram for one embodiment of a process for executing an affine inverse function instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Fig. 20D illustrates a diagram of one embodiment of a process for executing a binary finite field multiplication instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. DETAILED DESCRIPTION

[0014] The following description discloses instructions and processing logic to provide general-purpose GF(2") SIMD cryptographic arithmetic functionality, where in particular n is equal to 2 m(z. B. GF(2 8 ), GF(2 16 ), GF(2 32 ), ..., GF(2 128), etc.). Embodiments include a processor for decoding an affine SIMD transform instruction that specifies a source data operand, a transform matrix operand, and a translation vector. The transform matrix is applied to each element of the source data operand, and the translation vector is applied to each of the transformed elements. A result of the instruction is stored in a SIMD destination register. Some embodiments also decode a multiplicative SIMD binary finite field inverse function instruction to compute an inverse function in a binary finite field modulo an irreducible polynomial for each element of the source data operand.Some embodiments also decode an affine SIMD transform and multiplicative inverse function (or multiplicative inverse function and affine transform) instruction, where, either before or after the multiplicative inverse operation, the transformation matrix is applied to each element of the source data operand, and the translation vector is applied to each of the transformed elements. Some embodiments also decode a SIMD modulo reduction instruction to perform the reduction modulo a particular modulo polynomial p. sto calculate a finite number selected from polynomials in a binary finite field for which modulo reduction is provided by the instruction (or micro-instruction). Some embodiments also decode a binary field SIMD multiplication instruction that specifies first and second source data operands to multiply each corresponding pair of elements of the first and second source data operands modulo an irreducible polynomial.

[0015] It should be noted that SIMD arithmetic instructions for general-purpose cryptographic GF(2), as in the embodiments described herein, may be used to provide cryptographic arithmetic functionality in applications such as cryptographic protocols and Internet communications to ensure confidentiality, data integrity, identity verification, message content authentication, and message origin authentication for financial transactions, electronic shopping, electronic mail, software distribution, data storage, etc.

[0016] It is further noted that providing for the execution of instructions for at least: (1) an affine SIMD transformation specifying a source data operand, a transformation matrix operand, and a translation vector, wherein the transformation matrix is applied to each element of the source data operand and the translation vector is applied to each of the transformed elements; (2) a multiplicative SIMD inverse function for a binary finite field to compute an inverse function in a binary finite field modulo an irreducible polynomial for each element of the source data operand;(3) an affine SIMD transformation and multiplicative inverse function (or multiplicative inverse function and affine transformation) specifying a source data operand, a transformation matrix operand, and a translation vector, where either before or after the multiplicative inverse operation, the transformation matrix is applied to each element of the source data operand and the translation vector is applied to each of the transformed elements; (4) a modulo reduction to perform the reduction modulo a particular modulo polynomial p; sto calculate a binary finite field selected from polynomials in a binary finite field for modulo reduction provided by the instruction (or micro-instruction); (5) a binary finite field SIMD multiplication specifying first and second source data operands to multiply each corresponding pair of elements of the first and second source data operands modulo an irreducible polynomial; wherein the results of the instruction are stored in SIMD destination registers; may provide general-purpose GF(256) and / or other alternative cryptographic SIMD binary finite field arithmetic functionality in hardware and / or microcode sequences to support significant performance improvements for several important performance-critical applications without excessive or unreasonable functional units requiring additional circuitry, area, or power.

[0017] In the following description, numerous specific details are set forth, such as processing logic, processor types, microarchitectural conditions, events, activation mechanisms, and the like, in order to provide a more thorough understanding of embodiments of the present invention. However, it is understood that the invention may be practiced by one skilled in the art without such specific details. In addition, some well-known structures, circuits, and the like have not been shown in detail to avoid unnecessarily obscuring embodiments of the present invention.

[0018] Although the following embodiments are described with reference to a processor, other embodiments are applicable to other types of integrated circuits and logic devices. Similar technologies and teachings of embodiments of the present invention can be applied to other types of circuits or semiconductor devices that may benefit from higher pipeline throughput and improved performance. The teachings of embodiments of the present invention are applicable to any processor or machine that performs data manipulation. However, the present invention is not limited to processors or machines that perform 512-bit, 256-bit, 128-bit, 64-bit, 32-bit, 16-bit, or 8-bit data operations and can be applied to any processor or machine in which data manipulation or management is performed.Additionally, the following description provides examples, and the accompanying drawings show various examples for purposes of illustration. However, these examples should not be interpreted in a limiting sense, as they are intended merely to provide examples of embodiments of the present invention, rather than to provide a comprehensive list of all possible implementations of embodiments of the present invention.

[0019] Although the following examples describe instruction handling and dispatch in the context of execution units and logic circuits, other embodiments of the present invention may be achieved using data and / or instructions stored on a machine-readable, tangible medium that, when executed by a machine, cause the machine to perform functions consistent with at least one embodiment of the invention. In one embodiment, functions associated with embodiments of the present invention are embodied in machine-executable instructions. The instructions may be used to cause a general-purpose processor or a special-purpose processor programmed with the instructions to perform the steps of the present invention.

[0020] Embodiments of the present invention may be provided as a computer program product or software including a machine- or computer-readable medium having stored thereon instructions that can be used to program a computer (or other electronic device) to perform one or more operations according to embodiments of the present invention. Alternatively, steps of embodiments of the present invention could be performed by specific hardware components containing fixed-function logic for performing the steps, or by any combination of programmed computer components and fixed-function hardware components.

[0021] Instructions used to program logic to carry out embodiments of the invention may be stored in memory within the system, such as DRAM, cache, flash memory, or other memory. Furthermore, the instructions may be distributed over a network or using other computer-readable media. Thus, a machine-readable medium may be any mechanism for storing or transmitting information in a form that can be processed by a machine (e.g., a computer).a computer) readable medium includes, but is not limited to, floppy disks, optical disks, compact disks, read-only memories (CD-ROMs) and magneto-optical disks, read-only memories (ROMs), random access memories (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic or optical cards, flash memory, or any tangible machine-readable memory used to transmit information over the Internet via electrical, optical, acoustic, or other form of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.). Accordingly, a computer-readable medium includes any type of tangible machine-readable medium suitable for storing or transmitting electronic instructions or information in a form readable by a machine (e.g., a computer).

[0022] A design can go through several stages, from generation to simulation to manufacturing. Data representing a design can represent the design in several ways. First, as is useful for simulations, the hardware may be represented using a hardware description language or another functional description language. Additionally, a circuit-level model with logic and / or transistor gates may be produced at some stages of the design process. Furthermore, most designs reach a level of data representing the physical placement of various devices in the hardware model at some stage.In the case where conventional semiconductor manufacturing techniques are used, the data representing the hardware model may be the data indicating the presence or absence of various features on different mask layers for masks used to produce the integrated circuit. In each representation of the design, the data may be stored in any form of machine-readable medium. A memory or a magnetic or optical storage may be the machine-readable medium for storing information transmitted via optical or magnetic waves that are modulated or otherwise generated to transmit such information. When an electrical carrier wave indicating or carrying the code or design is transmitted, a new copy is made to the extent that copying, buffering, or retransmission of the electrical signal is performed.Thus, a communications service provider or network service provider can at least temporarily store an item, e.g., information encoded into a carrier wave incorporating techniques of embodiments of the present invention, on a tangible, machine-readable medium. Modern processors use a number of different execution units to execute a variety of code and instructions. Not all instructions are created equal, as some are faster to complete, while others require a number of clock cycles to complete. The faster the throughput of instructions, the better the overall performance of the processor. Thus, it would be beneficial to execute as many instructions as possible as quickly as possible. However, there are certain instructions that have greater complexity and are more demanding in terms of execution time and processor resources.For example, there are floating-point instructions, load / store operations, data movements, etc.

[0023] As more computer systems are used in internet, text, and multimedia applications, more processor support has been introduced over time. 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).

[0024] In one embodiment, the instruction set architecture (ISA) may be implemented by one or more micro-architectures, which include processor logic and circuitry used to implement one or more instruction sets. Accordingly, processors with different micro-architectures may share at least a portion of a common instruction set. For example, Intel® Pentium 4 processors, Intel® Core™ processors, and processors from Advanced Micro Devices, Inc. of Sunnyvale, CA, implement nearly identical versions of the x86 instruction set (with some extensions added with newer versions), but have different internal designs. Similarly, processors designed by other processor development companies, such as ARM Holding, Ltd., may have different internal designs., MIPS or their licensees or users share at least part of a common instruction set, but may include different processor designs. For example, the same ISA register architecture may be implemented in different ways in different microarchitectures using new or known techniques including dedicated physical registers, one or more dynamically allocated physical registers, a register renaming mechanism (e.g., the use of a register alias table (RAT)), a record buffer (ROB), and a retirement register file. In one embodiment, the registers may include one or more registers, register architectures, register files, or other register groups that may or may not be addressable by a software programmer.

[0025] In one embodiment, an instruction may include one or more instruction formats. In one embodiment, an instruction format may specify various fields (number of bits, location of bits, etc.) that may specify, among other things, the operation to be performed and the operand(s) on which the operation is to be performed. Some instruction formats may be further broken down, defined by instruction templates (or subformats). For example, the instruction templates of a given instruction format may be defined to have different subsets of the fields of the instruction format and / or defined to have different interpretations of a given field. In one embodiment, an instruction is expressed using an instruction format (and, if defined, in a given one of that instruction format's instruction templates) and specifies or indicates the operation and the operands on which the operation operates..

[0026] Scientific, financial, auto-vectored general-purpose, RMS (recognition, mining, and synthesis), and visual and multimedia applications (e.g., 2D / 3D graphics, image processing, video compression / decompression, speech recognition algorithms, and audio manipulation) may require the same operation to be performed on a large number of data elements. 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 technology can be used in processors that can logically divide the bits in a register into a number of fixed-size or variable-size data elements, each of which represents a separate value.For example, in one embodiment, the bits in a 64-bit register may be organized as a source operand containing four separate 16-bit data elements, each representing a separate 16-bit value. This data type may be referred to as a 'packet' data type or a 'vector' data type, and operands of this data type are referred to as packet operands or vector operands. In one embodiment, a packet operand or vector may be a sequence of packet elements stored in a single register, and a packet operand or vector operand may be a source or destination operand of a SIMD instruction (or 'packet instruction' or a 'vector instruction').In one embodiment, a SIMD instruction specifies a single vector operation to be performed on two source vector operands to produce a destination vector operand (also referred to as a result vector operand) of the same or different size, with the same or different number of data elements, and in the same or different data element order.

[0027] SIMD technology, such as that employed by Intel® Core™ processors, which have an instruction set that includes x86, MMX™, Streaming SIMD Extension (SSE), SSE2, SSE3, SSE4.1, and SSE4.2 instructions; ARM processors, such as the ARM Cortex® processor family, which have an instruction set that includes the Vector Floating Point (VFP) and / or NEON instructions; and MIPS processors, such as the Loongson processor family developed by the Institute of Computer Technology (ICT) of the Chinese Academy of Sciences, has enabled significant improvements in application performance (Core™ and MMX™ are registered trademarks or trademarks of Intel Corporation of Santa Clara, California).

[0028] In one embodiment, destination and source registers / data are generic terms to represent the source and destination of the corresponding data or operation. In some embodiments, they may be implemented by registers, memory, or other storage areas that have different names or functions than 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 in the same storage area (e.g., a SIMD register).In one embodiment, one of the source registers may also act as a destination register, for example by writing back the result of an operation performed on the first and second source data to one of the two source registers, which serves as a destination register.

[0029] Fig. 1A is a block diagram of an exemplary computer system configured with a processor including execution units to execute an instruction in accordance with an embodiment of the present invention. System 100 includes a component, such as a processor 102, for employing execution units containing logic to execute algorithms on process data in accordance with the present invention, such as in the embodiment described herein. System 100 represents processing systems based on the Pentium ® III-, PENTIUM ® 4, Xeon™, Itanium ®-, XScale™, and / or StrongARM™ microprocessors available from Intel Corporation of Santa Clara, California, although other systems (including personal computers having other microprocessors, development workstations, set-top boxes, and the like) may also be used. In one embodiment, system 100 may run a version of the WINDOWS™ operating system available from Microsoft Corporation of Redmond, Washington, although other systems (e.g., UNIX or Linux), embedded software, and / or graphical user interfaces may also be used. Thus, embodiments of the present invention are not limited to any specific combination of hardware circuitry and software.

[0030] Embodiments are not limited to computer systems. Alternative embodiments of the present invention may be used in other devices, such as portable devices and embedded applications. Some examples of more portable devices include cellular phones, Internet Protocol devices, digital cameras, personal digital assistants (PDAs), and portable PCs. Embedded applications may include a microcontroller, a digital signal processor (DSP), a system on a chip, network computers (NetPCs), set-top boxes, network hubs, wide area network switches (WAN switches), or another system capable of executing one or more instructions in accordance with at least one embodiment.

[0031] Fig.1A is a block diagram of a computer system 100 configured with a processor 102 including one or more execution units 108 for executing an algorithm to execute at least one instruction in accordance with an embodiment of the present invention. One embodiment may be described in the context of a single-processor desktop or server system, but 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 computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor implementing a combination of instruction sets, or any other processor device, such as a digital signal processor. Processor 102 is coupled to a processor bus 110, which can communicate data signals between processor 102 and other components of system 100. The elements of system 100 perform their conventional functions, which are well known to those skilled in the art.

[0032] In one embodiment, processor 102 includes an internal level 1 (L1) cache 104. Depending on the architecture, processor 102 may have a single internal cache or multiple levels of internal cache.

[0033] Alternatively, in another embodiment, the cache memory may be located external to processor 102. Other embodiments may also include a combination of both internal and external caches, depending on the specific implementation and requirements. Register file 106 may store different data types in various registers, including integer registers, floating-point registers, status registers, and instruction pointer registers.

[0034] Execution unit 108, which contains logic to perform integer and floating-point operations, is also located in processor 102. Processor 102 also includes a microcode ROM (ucode ROM) that stores microcode for certain macroinstructions. For one embodiment, execution unit 108 contains logic to handle a packet instruction set 109. By incorporating packet instruction set 109 into the instruction set of a general-purpose processor 102, along with associated circuitry to execute the instructions, the operations used by many multimedia applications can be performed using data packets in a general-purpose processor 102. Thus, many multimedia applications can be accelerated and run more efficiently by using the full width of a processor's data bus to perform operations on data packets.This can eliminate the need to transfer smaller units of data across the processor's data bus to perform one or more operations on data elements at the same time.

[0035] Alternative embodiments of an execution unit 108 may also be used in microcontrollers, embedded processors, graphics devices, DSPs, and other types of logic circuits. The system 100 includes a memory 120. The memory 120 may be a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory device, or another storage device. The memory 120 may store instructions and / or data represented by data signals that can be executed by the processor 102. A system logic chip 116 is coupled to the processor bus 110 and the memory 120. The system logic chip 116 in the illustrated embodiment is a memory control unit hub (MCH). The processor 102 may communicate with the MCH 116 via a processor bus 110.The MCH 116 provides a high-bandwidth memory path 118 to the memory 120 for storing instructions and data, and for storing graphics instructions, data, and textures. The MCH 116 serves to route data signals between the processor 102, the memory 120, and other components in the system 100, and to bridge the data signals between the processor bus 110, the memory 120, and the system I / O 122. In some embodiments, the system logic chip 116 may provide a graphics port for coupling to a graphics controller 112. The MCH 116 is coupled to the memory 120 via a memory interface 118. The graphics card 112 is coupled to the MCH 116 via an interconnect 114 using an accelerated graphics port (AGP) interconnect.

[0036] The system 100 uses a proprietary hub interface bus 122 to couple the MCH 116 to the I / O control unit hub (ICH) 130. The 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 for connecting peripherals to the memory 120, chipset, and processor 102. Some examples are the audio control unit, the firmware hub (flash BIOS) 128, the wireless transceiver 126, the data storage 124, the legacy I / O control unit containing user input and keyboard interfaces, a serial expansion port such as a serial bus, and the like. B. a universal serial bus (USB) and a network controller 134. The 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 devices.For another embodiment of a system, an instruction may be used in accordance with an embodiment using a system-on-chip. One embodiment of a system-on-chip includes a processor and memory. The memory for such a system is flash memory. The flash memory may be located on the same chip as the processor and other system components. In addition, other logic blocks, such as a memory controller or a graphics controller, may also be located on a system-on-chip.

[0037] Fig. Figure 1B illustrates a data processing system 140 implementing the principles of one embodiment of the present invention. It will be readily apparent to one skilled in the art that the embodiments described herein may be used with alternative processing systems without departing from the scope of the embodiments of the invention.

[0038] 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 architectural type, including, but not limited to, a CISC, RISC, or VLIW architecture. Processing core 159 may also be suitable for manufacturing in one or more process technologies and, by being represented on a machine-readable medium with sufficient fidelity, may be suitable for facilitating manufacturing.

[0039] The processing core 159 includes an execution unit 142, a group of register files 145, and a decoder 144. The processing core 159 also includes additional circuitry (not shown) that is not necessary for understanding embodiments of the present invention. The execution unit 142 is used to execute instructions received by the processing core 159. In addition to executing typical processor instructions, the execution unit 142 may execute instructions in a packet instruction set 143 for performing operations on packet data formats. The packet instruction set 143 includes instructions for implementing embodiments of the invention and other packet instructions. The execution unit 142 is coupled to the register file 145 by an internal bus. The register file 145 represents a memory area on the processing core 159 for storing information including data.As mentioned above, it should be understood that the memory location used to store the data packets is not critical. 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 the appropriate operations. In one embodiment, the decoder is used to interpret the instruction's opcode, which will indicate which operation should be performed on the corresponding data specified within the instruction.

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

[0041] One embodiment of data processing system 140 provides mobile, network, and / or wireless communication and a processing core 159 capable of performing SIMD operations, including string comparison operations. Processing core 159 may be programmed with various audio, video, image processing, and communication algorithms including discrete transforms such as a Walsh-Hadamard transform, a fast Fourier transform (FFT), a discrete cosine transform (DCT), and their respective inverse transforms; compression / decompression techniques such as color space transformation, video coding motion estimation, or video coding motion compensation; and modulation / demodulation (MODEM) functions such as pulse-coded modulation (PCM).

[0042] Fig.1C illustrates further alternative embodiments of a data processing system capable of executing instructions to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. According to an alternative embodiment, data processing system 160 may include a main processor 166, a SIMD coprocessor 161, a cache memory 167, and an input / output system 168. Input / output system 168 may optionally be coupled to a wireless interface 169. SIMD coprocessor 161 may execute operations including instructions in accordance with one embodiment.The processing core 170 may be suitable for manufacturing in one or more process technologies, and by being represented on a machine-readable medium with sufficient accuracy, it may be suitable for facilitating the manufacture of all or part of the data processing system 160 that includes the processing core 170.

[0043] For one embodiment, SIMD coprocessor 161 includes an execution unit 162 and a set of register files 164. One embodiment of main processor 166 includes a decoder 165 to identify instructions of instruction set 163, which includes instructions in accordance with one embodiment, for execution by execution unit 162. For alternative embodiments, SIMD coprocessor 161 also includes at least a portion of decoder 165B to decode instructions of instruction set 163. Processing core 170 also includes additional circuitry (not shown) that is not necessary for understanding embodiments of the present invention. In operation, main processor 166 executes a stream of data processing instructions that control data processing operations of a general type, including interaction with cache memory 167 and input / output system 168.Embedded in the stream of data processing instructions are SIMD coprocessor instructions. The decoder 165 of the main processor 166 recognizes these SIMD coprocessor instructions as instructions of a type that should be executed by an 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 where they are received by each attached SIMD coprocessor. In this case, the SIMD coprocessor 161 will accept and execute all received SIMD coprocessor instructions intended for it.

[0044] Data may be received via a wireless interface 169 for processing by the SIMD coprocessor instructions. In one example, voice communication may be received in the form of a digital signal, which may be processed by the SIMD coprocessor instructions to recover digital audio samples representative of the voice communication. In another example, compressed audio and / or video data may be received in the form of a digital bitstream, which may be processed by the SIMD coprocessor instructions to recover digital audio samples and / or video frames.For one embodiment of the processing core 170, the main processor 166 and a SIMD coprocessor 161 are integrated into a single processing core 170 that includes an execution unit 162, a set of register files 164, and a decoder 165 to recognize instructions of the instruction set 163 that includes instructions in accordance with one embodiment.

[0045] Fig.Figure 2 is a block diagram of the microarchitecture for a processor 200 including logic circuitry to execute instructions in accordance with one embodiment of the present invention. In some embodiments, an instruction in accordance with one embodiment may be implemented to operate on data elements having sizes of byte, word, doubleword, quadword, etc., as well as data types such as single-precision and double-precision integer and floating-point data types. In one embodiment, the in-order front-end 201 is the part of the processor 200 that fetches instructions to be executed and prepares them for use later in the processor pipeline. The front-end 201 may include multiple units. In one embodiment, the prefetch unit 226 fetches instructions from memory and inputs them to an instruction decoder 228, which in turn decodes or translates them.For example, in one embodiment, the decoder decodes a received instruction into one or more operations, referred to as "micro-instructions" or "micro-operations" (also referred to as micro-ops or uops), that the machine can perform. In other embodiments, the decoder parses the instruction into an opcode and corresponding data and control fields used by the micro-architecture to perform operations in accordance with an embodiment. In one embodiment, trace cache 230 takes decoded uops and assembles them into program-ordered sequences, or traces, in uop queue 234 for execution. When trace cache 230 encounters a complex instruction, microcode ROM 232 provides the uops needed to complete the operation.

[0046] Some instructions are implemented into a single micro-op, while others require multiple micro-ops to complete the entire 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, an instruction may be decoded into a small number of micro-ops for processing in instruction decoder 228. In another embodiment, an instruction may be stored in microcode ROM 232 should a number of micro-ops be required to perform the operation. Trace cache 230 refers to a programmable entry point logic array (entry point PLA) for determining a correct microinstruction pointer for reading microcode sequences to complete one or more instructions from microcode ROM 232 in accordance with one embodiment.After the microcode ROM 232 finishes sequencing the micro-ops for an instruction, the machine's front end 201 resumes fetching micro-ops from the trace cache 230.

[0047] The out-of-order execution engine 203 is where instructions are prepared for execution. The out-of-order execution logic includes a number of buffers to smooth and reorder the flow of instructions to optimize performance as they traverse the pipeline and are scheduled for execution. The allocation logic allocates the machine buffers and resources each uop needs to execute. The register renaming logic renames logic registers to entries in a register file. The allocation unit also assigns an entry point for each uop in one of two uop queues, one for memory operations and one for out-of-memory operations, before the instruction scheduling units: memory scheduling unit, fast scheduling unit 202, fast / general floating-point scheduling unit 204, and simple floating-point scheduling unit 206.The uop scheduling units 202, 204, and 206 determine when a uop is ready for execution based on the readiness of its dependent input register operand sources and the availability of the execution resources the uops require to complete their operation. The fast scheduling unit 202 of one embodiment can schedule on either half of the main clock cycle, while the other scheduling units can only schedule once per main processor clock cycle. The scheduling units arbitrate the dispatch ports to schedule uops for execution.

[0048] Register files 208, 210 are located between scheduling units 202, 204, 206 and execution units 212, 214, 216, 218, 220, 222, 224 in execution block 211. There is a separate register file 208, 210 for integer and floating-point operations. Each register file 208, 210 of one embodiment also includes a bypass network that can bypass just-completed results that have not yet been written to the register file or forward them to new dependent uops. Integer register file 208 and floating-point register file 210 can also communicate data with each other. For one embodiment, integer register file 208 is split into two separate register files: one register file for the lower 32 bits of data and a second register file for the higher 32 bits of data.The floating point register file 210 of one embodiment has 128-bit wide entries because floating point instructions typically have operands ranging from 64 to 128 bits wide.

[0049] Execution block 211 contains execution units 212, 214, 216, 218, 220, 222, and 224, where the instructions are actually executed. This section contains register files 208 and 210, which store the integer and floating-point data operand values that the microinstructions must execute. Processor 200 of one embodiment may include a number of 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 shift unit 224. For one embodiment, floating-point execution blocks 222 and 224 perform floating-point, MMX, SIMD, and SSE, among other operations. The floating-point ALU 222 of one embodiment includes a 64-bit by 64-bit floating-point divide unit for performing division, square root, and remainder micro-ops. For embodiments of the present invention, instructions involving a floating-point value may be handled with the floating-point hardware.In one embodiment, the ALU operations go to the high-speed ALU execution units 216, 218. .

[0050] The fast ALUs 216, 218 of one embodiment can perform fast operations with an effective latency of half a clock cycle. For one embodiment, the most complex integer operations go to the slow ALU 220 because the slow ALU 220 includes integer execution hardware for long-latency operations such as multiplier, shift, flag logic, and branch processing. Memory load / store operations are performed by the ALUs 212, 214. For one embodiment, the ALUs 216, 218, 220 are described in the context of performing integer operations on 64-bit data operands. In alternative embodiments, the ALUs 216, 218, 220 may be implemented to support various data bits, including 16, 32, 128, 256, etc. Similarly, the floating point units 222, 224 may be implemented to support a range of operands having bits of different widths.For one embodiment, the floating point units 222, 224 may operate on 128-bit wide data packet operands in conjunction with SIMD and multimedia instructions.

[0051] In one embodiment, the uops scheduling units 202, 204, 206 dispatch dependent operations before the predecessor load has completed execution. Because the uops are speculatively scheduled and executed in the processor 200, the processor 200 also includes logic to handle memory errors. If a data load is missing from the data cache, dependent operations may be executing in the pipeline that have temporarily left dirty data in the scheduling unit. A retry mechanism tracks instructions that use dirty data and reexecutes them. Only the dependent operations need to be retried, and the independent ones are allowed to complete. The scheduling units and retry mechanism of one embodiment of a processor are also designed to trap instructions that provide general-purpose GF(256) SIMD cryptographic arithmetic functionality.

[0052] The term "registers" can refer to the processor's own memory locations used as part of instructions to identify operands. In other words, registers can be those that can be accessed from outside the processor (from the programmer's perspective). However, the registers of an embodiment should not be limited in meaning to a specific circuit type.

[0053] Rather, a register of one embodiment can store and provide data and perform the functions described herein. The registers described herein can be implemented by circuitry within a processor using a number of different techniques, such as dedicated physical registers, dynamically allocated physical registers using register renaming, combinations of dedicated and dynamically allocated physical registers, etc. In one embodiment, integer registers store thirty-two-bit integer data. A register file of one embodiment also includes eight multimedia SIMD registers for packet data. For the discussion below, registers are understood to be data registers designed to contain data packets, such as64-bit wide MMX™ registers (sometimes referred to as 'mm' registers) in microprocessors released with MMX technology from Intel Corporation of Santa Clara, California. These MMX registers, available in both integer and floating-point forms, can operate on data packet elements accompanying SIMD and SSE instructions. Similarly, 128-bit wide XMM registers related to SSE2, SSE3, SSE4 technology, or beyond (generically referred to as "SSEx" technology) can also be used to hold such data packet operands. In one embodiment, the registers for storing packet data and integer data need not distinguish between the two data types. In one embodiment, integer and floating-point are contained either in the same register file or in different register files.Furthermore, in one embodiment, floating point and integer data may be stored in different registers or in the same register.

[0054] In the examples in the following figures, a number of data operands are described. Fig. 3A illustrates various representations of data packet types in multimedia registers according to one embodiment of the present invention. Fig.Figure 3A illustrates data types for a byte packet 310, a word packet 320, and a double-word packet (dword packet) 330 for 128-bit wide operands. The byte packet format 310 of this example is 128 bits long and contains sixteen byte packet data elements. A byte is defined here as 8 data bits. Information for each byte data element is stored in bits 7 through 0 for byte 0, bits 15 through 8 for byte 1, bits 23 through 16 for byte 2, and finally bits 120 through 127 for byte 15. Thus, all available bits in the register are used. This memory arrangement increases the memory efficiency of the processor. In addition, when accessing sixteen data elements, an operation can now be performed in parallel on sixteen data elements.

[0055] In general, a data element is individual data stored in a single register or memory location with other data elements of the same length. In data packet sequences related to SSEx technology, the number of data elements stored in an XMM register is 128 bits divided by the length in bits of an individual data element. Similarly, in data packet sequences related to MMX and SSE technology, the number of data elements stored in an MMX register is 64 bits divided by the length in bits of an individual data element. Although the Fig.3A are 128 bits long, embodiments of the present invention may also operate with 64-bit, 256-bit, 512-bit, or other sized operands. The word packet format 320 of this example is 128 bits long and contains eight word packet data elements. Each word packet contains sixteen bits of information. The double word packet format 330 of Fig. 3A is 128 bits long and contains four double-word packet data elements. Each double-word packet data element contains 32 bits of information. A quad-word packet is 128 bits long and contains two quad-word packet data elements.

[0056] Fig.Figure 3B illustrates alternative in-register data storage formats. Each data packet may contain more than one independent data element. Three data packet formats are illustrated: half packet 341, single packet 342, and double packet 343. One embodiment of half packet 341, single packet 342, and double packet 343 contains fixed-point data elements. For an alternative embodiment, one or more of half packets 341, single packet 342, and double packet 343 may contain floating-point data elements. One alternative embodiment of half packet 341 is one hundred twenty-eight bits long and contains eight 16-bit data elements. One embodiment of single packet 342 is one hundred twenty-eight bits long and contains four 32-bit data elements. One embodiment of double packet 343 is one hundred twenty-eight bits long and contains two 64-bit data elements.It should be noted that such data packet formats can be further extended to other register lengths, for example to 96 bits, 160 bits, 192 bits, 224 bits, 256 bits, 512 bits or more.

[0057] Fig.3C illustrates various representations of signed and unsigned data packet types in multimedia registers according to one embodiment of the present invention. The unsigned byte packet representation 344 illustrates the storage of an unsigned byte packet in a SIMD register. Information for each byte data element is stored in bits seven through bit zero for byte zero, bit fifteen through bit eight for byte one, bit twenty-three through bit sixteen for byte two, and so on, and finally bit one hundred twenty through bit one hundred twenty-seven for byte fifteen. Thus, all available bits in the register are used. This storage arrangement can increase the memory efficiency of the processor. In addition, when accessing sixteen data elements, an operation can now be performed in parallel on sixteen data elements.The signed byte packet representation 345 represents the storage of a signed byte packet. Note that the eighth bit of each byte data item is the sign indication. The unsigned word packet representation 346 represents how words seven through word zero are stored in a SIMD register. The signed word packet representation 347 is similar to the in-register unsigned word packet representation 346. Note that the sixteenth bit of each word data item is the sign indication. The unsigned double word packet representation 348 shows how double word data items are stored. The signed double word representation 349 is similar to the in-register unsigned double word representation 348. Note that the required sign bit is the thirty-second bit of each double word data item.

[0058] Fig.3D is an illustration of one embodiment of an operation coding (opcode) format 360 having thirty-two or more bits and register / memory operand addressing modes corresponding to a type of opcode format described in the "Intel® 64 and IA-32 Intel Architecture Software Developer's Manual Combined Volumes 2A and 2B: Instruction Set Reference AZ," which is the one available from Intel Corporation, Santa Clara, CA, on the Internet (www) at intel.com / products / processor / manuals / . In one embodiment, an instruction may be encoded by one or more of fields 361 and 362. Up to two operand locations per instruction may be identified, including up to 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 different.For an alternative embodiment, the destination operand identifier 366 is the same as the source operand identifier 365, while in other embodiments they are different. In one embodiment, one of the source operands specified by the.

[0059] Source operand identifiers 364 and 365 are overwritten by the results of the instructions, while in other embodiments, identifier 364 corresponds to a source register element and identifier 365 corresponds to a destination register element. For one embodiment, operand identifiers 364 and 365 can be used to identify 32-bit or 64-bit source and destination operands. Fig.3E is an illustration of another alternative opcode format 370 having forty or more bits. Opcode format 370 corresponds to opcode format 360 and includes an optional prefix byte 378. An instruction according to one embodiment may be encoded by one or more of fields 378, 371, and 372. Up to two operand locations per instruction may be identified by source operand identifiers 374 and 375 and by prefix byte 378. For one embodiment, prefix byte 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 different. For an alternative embodiment, the destination operand identifier 376 is the same as the source operand identifier 375, while in other embodiments they are different.In one embodiment, an instruction operates on one or more of the operands identified by operand identifiers 374 and 375, and one or more of the operands identified by operand identifiers 374 and 375 are overwritten by the results of the instruction. In other embodiments, the operands identified by operand identifiers 374 and 375 are written to another data element in another register. Opcode formats 360 and 370 enable register-to-register, memory-to-register, register-to-memory, register-to-register, register-immediate, and register-to-memory addressing, specified in part by MOD fields 363 and 373 and by optional scale, index, base, and displacement bytes.

[0060] Next, continue 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 performed by a coprocessor data processing (CDP) instruction. The opcode format 380 maps to such a CDP instruction, which includes CPD opcode fields 382 and 389. The type of CDP instruction operations may, for alternative embodiments, be encoded by one or more of fields 383, 384, 387, and 388. Up to three operand locations per instruction may be identified, including up to two source operand identifiers 385 and 390 and one destination operand identifier 386. One embodiment of the coprocessor can operate on 8-, 16-, 32-, and 64-bit values. For one embodiment, an instruction is executed on integer data elements. In some embodiments, an instruction can be executed conditionally using condition field 381.For some embodiments, the source data sizes may be encoded by field 383. In some embodiments, zero (Z), negative (N), carry (C), and overflow (V) detection may be performed on SIMD fields. For some instructions, the type of saturation may be encoded by field 384.

[0061] Next, continue to Fig. 3G, which is an illustration of another alternative operation coding (opcode) format 397 for providing general-purpose GF(256) SIMD cryptographic arithmetic functionality according to another embodiment, corresponding to a type of opcode format described in "Intel® Advanced Vector Extensions Programming Reference" available from Intel Corp., Santa Clara, CA on the Internet (www) at intel.com / products / processor / manuals / .

[0062] The original x86 instruction set provided for a 1-byte opcode with various formats of address syllable and immediate operand contained in additional bytes, the presence of which was known starting with the first "opcode" byte. In addition, there were certain byte values reserved as opcode modifiers (called prefixes because they had to be placed before the instruction). When the original range of 256 opcode bytes (containing these special prefix values) was exhausted, a single byte was reserved as an escape to a new set of 256 opcodes. As vector instructions (e.g., SIMD) were added, a need for more opcodes arose, and the "two-byte" opcode mapping was also inadequate, even when expanded through the use of prefixes.For this purpose, new commands have been added in additional maps that use 2 bytes plus an optional prefix as an identifier.

[0063] Additionally, to allow for additional registers in 64-bit mode, an additional prefix (referred to as "REX") may be used between the prefixes and the opcode (and any escape bytes necessary to specify the opcode). In one embodiment, the REX may have 4 "payload" bits to indicate the use of additional registers in 64-bit mode. In other embodiments, it 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 generically represented by the following: [prefixes] [rex] escape [escape2] opcode modrm (etc.)

[0064] Opcode format 397 corresponds to opcode format 370 and includes optional VEX prefix bytes 391 (beginning with C4 hex in one embodiment) to replace most other commonly used old instruction prefix bytes and escape codes. For example, the following illustrates an embodiment that uses two fields to encode an instruction, which can be used when a second escape code is present in the original instruction, or when extra bits (e.g., the XB and W fields) in the REX field must be used. In the embodiment illustrated below, the old escape is represented by a new escape value, old prefixes are fully compressed as part of the "payload" bytes, old prefixes are reused and available for future expansion, the second escape code is compressed into a "Map" field, where future mapping or space is available, and new features are added (e.g.,increased vector length and an additional source register identifier).

[0065] An instruction according to one embodiment may be encoded by one or more of fields 391 and 392. Up to four operand locations per instruction may be identified by field 391 in combination with source operand identifiers 374 and 375, and in combination with an optional scale index base (SIB) identifier 393, an optional displacement identifier 394, and an optional immediate byte 395. For one embodiment, VEX prefix bytes 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 be redundant to opcode format 370, while in other embodiments they may be different.Opcode formats 370 and 397 allow register-to-register, memory-to-register, register-to-memory, register-to-register, register-immediate, and register-to-memory addressing, which are specified in part by the MOD field 373 and by the optional (SIB) identifier 393, an optional relocation identifier 394, and an optional immediate byte 395.

[0066] Next, continue to Fig.3H, which is an illustration of another alternative operation encoding (opcode) format 398 for providing general-purpose GF(256) SIMD cryptographic arithmetic functionality according to another embodiment. Opcode format 398 corresponds to opcode formats 370 and 397 and includes optional EVEX prefix bytes 396 (beginning with 62 hex in one embodiment) to replace most other commonly used legacy instruction prefix bytes and escape codes and to provide additional functionality. An instruction according to one embodiment may be encoded by one or more of fields 396 and 392. Up to four operand locations per instruction and one mask may be identified by field 396 in combination with source operand identifiers 374 and 375 and in combination with an optional scale index base (SIB) identifier 393, an optional displacement identifier 394, and an optional immediate byte 395.For one embodiment, EVEX prefix bytes 396 may be used to identify 32-bit or 64-bit source and destination operands and / or a 128-bit, 256-bit, or 512-bit SIMD register or memory operand. For one embodiment, the functionality provided by opcode format 398 may be redundant to opcode formats 370 or 397, while in other embodiments they are different. Opcode format 398 enables register-to-register, memory-to-register, register-to-memory, register-to-register, register-immediate, and register-to-memory addressing with masks specified in part by MOD field 373 and by optional (SIB) identifier 393, an optional relocation identifier 394, and an optional immediate byte 395.The general format of at least one instruction set (which generally corresponds to format 360 and / or format 370) is generically represented by the following: evex1 RXBmmmmm WvvvLpp evex4 opcode modrm [sib] [disp] [imm].

[0067] For one embodiment, an instruction encoded according to EVEX format 398 may include additional "payload" bits that may be used to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality with additional novel features such as a user-configurable mask register or an additional operand, or selections from 128-bit, 256-bit, or 512-bit vector registers or more registers from which to select, etc. For example, if VEX format 397 may be used to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality with an implicit mask, EVEX format 398 may be used to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality with an explicit user-configurable mask.Additionally, if the VEX format 397 can be used to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality on 128-bit or 256-bit registers, the EVEX format 398 can be used to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality on 128-bit, 256-bit, 512-bit, or larger (or smaller) vector registers.

[0068] Example instructions to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality are illustrated by the following examples: command Source1 / Destination Source2 Source3 Source4 Description Affine Xfm bytes Vmm1 Vmm2 Vmm3 / Imm8 Mem64 Perform a matrix multiplication in GF(256) on the byte vectors in Vmm2 using the 8x8 matrix in Vmm3 or Mem64 and add the byte vector in Imm8 to each. Store the transformed byte vectors in Vmm1. Affine Xfm words Vmm1 Vmm2 Vmm3 / Imm16 Mem256 Perform a matrix multiplication in GF(65536) on the word vectors in Vmm2 using the 16x16 matrix in Vmm3 or Mem256 and add the word vector in Imm16 to each. Store the transformed word vectors in Vmm1. GF256 1B Reverse function Vmm1 Vmm2 Performing a multiplicative inverse function in GF(256) on the byte vectors in Vmm2 modulo the polynomial, x 8 +x 4 +x 3 +x+1. Store the inverse byte vectors in Vmm1. GF inverse bytes Vmm1 Vmm2 Imm8 Perform a multiplicative inverse function on the byte vectors in Vmm2 in a Galois field and modulo a polynomial selected by the control value in Imm8. Store the inverse byte vectors in Vmm1. GF256 1B Multiplication Vmm1 Vmm2 Vmm3 / Mem-V Multiply in GF(256) the byte vectors in Vmm2 with the byte vectors in Vmm3 or Mem-V modulo the polynomial x 8 +x 4 +x 3 +x+1. Store the product byte vectors in V mm1. GF Multiplication Fsize Vmm1 Vmm2 Vmm3 / Imm8 Mem-V Performing a multiplication in a Galois field and modulo a polynomial that by the control value selected in Imm8, of Fsize vectors in Vmm2 with Fsize vectors in Vmm3 or Mem-V. Store the product vectors in Vmm1.

[0069] It should be noted that general-purpose GF(2") SIMD cryptographic arithmetic instructions, as in the embodiments described herein, may be used to provide cryptographic arithmetic functionality in applications such as cryptographic protocols and Internet communications to ensure confidentiality, data integrity, identity verification, message content authentication, and message origin authentication for financial transactions, electronic shopping, electronic mail, software distribution, data storage, etc.

[0070] It is further noted that providing for the execution of instructions for at least: (1) an affine SIMD transformation specifying a source data operand, a transformation matrix operand, and a translation vector, wherein the transformation matrix is applied to each element of the source data operand and the translation vector is applied to each of the transformed elements; (2) a multiplicative SIMD inverse function for a binary finite field to compute an inverse function in a binary finite field modulo an irreducible polynomial for each element of the source data operand;(3) an affine SIMD transformation and multiplicative inverse function (or multiplicative inverse function and affine transformation) specifying a source data operand, a transformation matrix operand, and a translation vector, wherein either before or after the multiplicative inverse operation, the transformation matrix is applied to each element of the source data operand and the translation vector is applied to each of the transformed elements; (4) an integer reduction to calculate the reduction modulo a specific modulo polynomial p selected from polynomials in a binary finite field, for which modulo reduction is provided by the instruction (or micro-instruction); (5) a binary SIMD multiplication of a binary field specifying first and second source data operands to multiply each corresponding pair of elements of the first and second source data operands modulo an irreducible polynomial;wherein the results of the instructions are stored in SIMD destination registers; can provide general-purpose GF(256) and / or other alternative binary finite field cryptographic SIMD arithmetic functionality in hardware and / or microcode sequences to support significant performance improvements for several important performance-critical applications without excessive or inappropriate functional units requiring additional circuitry, area, or power. ; Fig. 4A is a block diagram illustrating an in-order pipeline and a register rename stage, out-of-order subject / execution pipeline according to at least one embodiment of the invention. Fig.4B is a block diagram illustrating an in-order architecture core and register renaming logic, out-of-order object / execution logic to be included in a processor according to at least one embodiment of the invention. The solid-line frames in Fig. 4A represent the in-order pipeline, while the dashed-line frames represent the register renaming, out-of-order subject / execution pipeline. Similarly, the solid-line frames in Fig. 4B represents the in-order architectural logic, while the dashed line frames represent the register renaming logic and out-of-order subject / execution logic.

[0071] In Fig.4A, a processor pipeline 400 includes a fetch stage 402, a length decode stage 404, a decode stage 406, an allocation stage 408, a rename stage 410, a scheduling stage (also referred to as a dispatch or item stage) 412, a register read / memory read stage 414, an execution stage 416, a write-back / memory write stage 418, an exception handling stage 422, and a commit stage 424.

[0072] In Fig. 4B, arrows indicate a coupling between two or more units, and the direction of the arrow indicates a direction of data flow between these units.

[0073] Fig. 4B shows the processor core 490, which includes a front-end unit 430 coupled to an execution engine unit 450, and both are coupled to a memory unit 470.

[0074] Core 490 may be a reduced instruction set (RISC) core, a complex instruction set (CISC) core, a very long instruction word (VLIW) core, a hybrid core, or a core of an alternative type. As yet another option, core 490 may be a special-purpose core, such as a network or communications core, a compression engine, a graphics core, or the like.

[0075] The front-end unit 430 includes a branch prediction unit 432 coupled to an instruction cache unit 434, which is coupled to an instruction translation lookaside buffer (TLB) 436, which is coupled to an instruction fetch unit 438, which is coupled to a decode unit 440. The decode unit, or decoder, may decode instructions and generate as an output one or more micro-operations, microcode entry points, microinstructions, other instructions, or other control signals that are decoded from, or otherwise reflect, or are derived from the original instructions. The decoder may be implemented using many different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memories (microcode ROMs), etc.The instruction cache unit 434 is further coupled to a level 2 (L2) cache unit 476 in the memory unit 470. The decode unit 440 is coupled to a rename / allocation unit 452 in the execution engine unit 450.

[0076] The execution engine unit 450 includes a rename / allocation unit 452 coupled to a retirement unit 454, and a group of one or more scheduling units 456. The scheduling unit(s) 456 represent any number of different scheduling units, including reservation stations, central instruction windows, etc. The scheduling unit(s) 456 are coupled to the physical register file unit(s) 458. Each of the physical register file unit(s) 458 represents one or more physical register files, with different ones storing one or more different data types, such as scalar integer, scalar floating-point, integer packet, floating-point packet, vector integer, vector floating-point, etc., status (e.g., an instruction pointer, which is the address of the next instruction to be executed), etc.The physical register file unit(s) 458 are overlaid by the retirement unit 454 to illustrate various ways in which register renaming and out-of-order execution may be implemented (e.g., using record buffer(s) and a retirement register file(s); using a future file(s), history buffer(s), and a retirement register file(s); using register maps and a pool of registers; etc.). In general, the architectural registers are visible from outside the processor or from the programmer's perspective. The registers are not restricted to any known circuit type. Various different register types are suitable as long as they can store and provide data as described herein.Examples of suitable registers include, but are not limited to, dedicated physical registers, dynamically allocated registers using register renaming, combinations of dedicated and dynamically allocated physical registers, etc. The retirement unit 454 and the physical register file unit(s) 458 are coupled to the execution cluster(s) 460. The execution cluster(s) 460 include a group of one or more execution units 462 and a group of one or more memory access units 464. The execution units 462 can perform various operations (e.g., shifts, addition, subtraction, multiplication) and on various data types (e.g., scalar floating point, integer packet, floating point packet, vector integer, vector floating point).Although some embodiments may include a number of execution units dedicated to specific functions or groups of functions, other embodiments may include only one execution unit or multiple execution units that all execute all functions. The scheduling unit(s) 456, physical register file unit(s) 458, and execution cluster(s) 460 are shown as possibly multiple because particular embodiments create separate pipelines for specific types of data / operations (e.g.,a scalar integer pipeline, a scalar floating point pipeline / integer packet / floating point packet / vector integer / vector floating point pipeline, and / or a memory access pipeline, each of which has its own scheduling unit, physical register file unit, and / or execution cluster; and in the case of a separate memory access pipeline, special embodiments are implemented in which only the execution cluster of that pipeline includes the memory access unit(s) 464. It should also be understood that when separate pipelines are used, one or more of these pipelines may be out-of-order subject / execution and the remainder may be in-order.

[0077] The group of memory access units 464 is coupled to the memory unit 470, which includes a data TLB unit 472 coupled to a data cache unit 474 coupled to a level 2 (L2) cache unit 476. In an exemplary embodiment, the memory access units 464 may include a load unit, a store address unit, and a store data unit, each of which is coupled to the data TLB unit 472 in the memory unit 470. The L2 cache unit 476 is coupled to one or more cache levels and ultimately to main memory.

[0078] For example, the exemplary register renaming, out-of-order subject / execution core architecture may implement pipeline 400 as follows: 1) instruction fetch 438 performs fetch and length decode stages 402 and 404; 2) decode unit 440 performs decode stage 406; 3) rename / allocation unit 452 performs allocation stage 408 and rename stage 410; 4) scheduling unit(s) 456 perform scheduling stage 412; 5) physical register file unit(s) 458 and memory unit 470 perform register read / memory read stage 414; execution cluster 460 performs execution stage 416; 6) the memory unit 470 and the physical register file unit(s) 458 perform the write-back / memory write stage 418; 7) various units may participate in the exception handling stage 422;and 8) the retire unit 454 and the physical register file unit(s) 458 perform the commit stage 424. The core 490 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added with newer versions); the MIPS instruction set from MIPS Technologies of Sunnyvale, CA; the ARM instruction set (with optional additional extensions, such as NEON) from ARM Holdings of Sunnyvale, CA).

[0079] It should be understood that the core can support multithreading (executing two or more parallel groups of operations or threads) and can do so in several different ways, including time-sliced multithreading, simultaneous multithreading (where a single physical core provides a logical core for each of the threads, with that physical core performing simultaneous multithreading), or a combination thereof (e.g., time-sliced fetch and decode followed by simultaneous multithreading, such as in Intel® Hyperthreading Technology).

[0080] 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 include a single internal cache for both instructions and data, such as an internal level 1 (L1) cache or multiple-level internal cache. In some embodiments, the system may include a combination of an internal cache and an external cache external to the core and / or the processor. Alternatively, the entire cache may be external to the core and / or the processor.

[0081] Fig.Figure 5 is a block diagram of a single-core processor and a multi-core processor 500 with integrated memory controller and graphics according to embodiments of the invention. The solid-line frames in Fig. 5 illustrate a processor 500 with a single core 502A, a system agent 510, a group of one or more bus control units 516, while the optional addition of the dashed line frames illustrates an alternative processor 500 with multiple cores 502A-N, a group of one or more integrated memory control units 514 in the system agent unit 510, and integrated graphics logic 508.

[0082] The memory hierarchy includes one or more cache levels within the cores, a group of one or more shared cache units 506, and external memory (not shown) coupled to the group of integrated memory controllers 514. The group of shared cache units 506 may include one or more mid-level caches, such as Level 2 (L2), Level 3 (L3), Level 4 (L4), or other cache levels, a last-level cache (LLC), and / or combinations thereof. While in one embodiment, a ring-based interconnect unit 512 interconnects the integrated graphics logic 508, the group of shared cache units 506, and the system agent unit 510, alternative embodiments may utilize any number of known techniques for interconnecting such units.

[0083] In some embodiments, one or more of cores 502A-N are capable of multithreading. System agent 510 includes the components that coordinate and operate cores 502A-N. System agent unit 510 may, for example, include a power control unit (PCU) and a display unit. The PCU may be or include logic and components needed to regulate the power state of cores 502A-N and integrated graphics logic 508. The display unit is used to drive one or more external display devices.

[0084] Cores 502A-N may be homogeneous or heterogeneous in terms of architecture and / or instruction set. For example, some cores 502A-N may be in-order, while others are out-of-order. As another example, two or more cores 502A-N may be capable of executing the same instruction set, while others may only be capable of executing a subset of that instruction set or a different instruction set.

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

[0086] The Fig. 6-8 are exemplary systems suitable for accommodating the processor 500, while Fig.9 is an exemplary system-on-chip (SoC) that may include one or more of cores 502. Other system designs and configurations known in the art for laptops, desktops, portable PCs, personal digital assistants, development workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, mobile phones, portable media players, wearable devices, and various other electronic devices are also suitable. In general, a wide variety of systems or electronic devices that can integrate a processor and / or other execution logic as disclosed herein are generally suitable.

[0087] Now referring to Fig.6, a block diagram of a system 600 in accordance with an embodiment of the present invention is shown. The system 600 may include one or more processors 610, 615 coupled to the graphics memory control unit hub (GMCH) 620. The optional nature of additional processors 615 is described in Fig. 6 marked by dashed lines.

[0088] Each processor 610, 615 may be a version of processor 500. However, it is noted that it is unlikely that integrated graphics logic and integrated memory controllers would be present in processors 610, 615. Fig. Figure 6 illustrates that the GMCH 620 may be coupled to a memory 640, which may be, for example, a dynamic random access memory (DRAM). The DRAM may be associated with a non-volatile cache for at least one embodiment.

[0089] The GMCH 620 may be a chipset or a portion of a chipset. The GMCH 620 may communicate with the processor(s) 610, 615 and control the interaction between the processor(s) 610, 615 and the memory 640. The GMCH 620 may also operate as an accelerated bus interface between the processor(s) 610, 615 and other elements of the system 600. For at least one embodiment, the GMCH 620 communicates with the processor(s) 610, 615 via a multi-drop bus, such as a front-side bus (FSB) 695.

[0090] In addition, GMCH 620 is coupled to a display device 645 (such as a flat panel display). The GMCH 620 may include an integrated graphics accelerator. The GMCH 620 is further coupled to an input / output controller hub (I / O controller hub) 650, which may be used to couple various peripheral devices to system 600. For example, in the embodiment of Fig.6, an external graphics device 660 is shown, which may be a discrete graphics device coupled to ICH 650, along with another peripheral device 670.

[0091] Alternatively, additional or different processors may also be present in system 600. For example, additional processor(s) 615 may include additional processors that are the same as processor 610, additional processor(s) that are heterogeneous or asymmetric to processor 610, accelerators (such as graphics accelerators or digital signal processing (DSP) units), field-programmable gate arrays, or any other processor. There may be a number of differences between the physical resources 610, 615 with respect to a spectrum of metrics of merit, including architectural, micro-architectural, thermal, power consumption characteristics, and the like. These differences may effectively manifest as asymmetry and heterogeneity among the processors 610, 615. For at least one embodiment, the various processors 610, 615 may be arranged in the same chip package.

[0092] Now referring to Fig. 7 is a block diagram of a second system 700 in accordance with an embodiment of the present invention. As shown in Fig. As shown in Figure 7, multiprocessor system 700 is a point-to-point interconnect system and includes a first processor 770 and a second processor 780 coupled via a point-to-point interconnect 750. Each of processors 770 and 780 may be a version of processor 500, such as one or more of processors 610, 615.

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

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

[0095] Processors 770, 780 may each exchange information with a chipset 790 via individual PP interfaces 752, 754 using point-to-point interface circuits 776, 794, 786, 798. Chipset 790 may also exchange information with a high-performance graphics circuit 738 via a high-performance graphics interface 739.

[0096] A shared cache (not shown) may be included in each processor or external to both processors, but connected to the processors via PP interconnection, so that the local cache information of one or both processors may be stored in the shared cache if a processor is placed in a low power mode.

[0097] Chipset 790 may be coupled to a first bus 716 via an interface 796. In one embodiment, the first bus may be a peripheral component interconnect (PCI) bus or a bus such as a PCI Express bus or other third-generation I / O interconnect bus, although the scope of the present invention is not so limited.

[0098] As in Fig.7, various I / O devices may be coupled to the first bus 716, along with a bus bridge 718 that couples the first bus 716 to a 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, including, for example, a keyboard and / or mouse 722, communication devices 727, and a storage unit 728, such as a disk drive or other mass storage device that may contain instructions / code and data 730, in one embodiment. Furthermore, an audio I / O 724 may be coupled to the second bus 720. It should be noted that other architectures are possible. For example, instead of the point-to-point architecture of Fig. 7 implement a multidrop bus or other such architecture.

[0099] Now referring to Fig.8, a block diagram of a system 800 in accordance with an embodiment of the present invention is shown. Like elements in Fig. 7 and Fig. 8 bear the same reference numerals, and certain aspects of Fig. 7 were from Fig. 8 omitted to avoid obscuring other aspects of Fig. 8 to be avoided.

[0100] Fig. Figure 8 illustrates that processors 870, 880 may include integrated memory and I / O control logic (“CL”) 872, 882, respectively. For at least one embodiment, CL 872, 882 may include integrated memory controllers, such as those described above in connection with the Fig. 5 and Fig. 7. In addition, the CL 872, 882 may also contain I / O control logic. Fig.Figure 8 illustrates that not only are the memories 832, 834 coupled to the CL 872, 882, but also that the I / O devices 814 are also coupled to the control logic 872, 882. Old I / O devices 815 are coupled to the chipset 890.

[0101] Now referring to Fig. 9, a block diagram of an SoC 900 in accordance with an embodiment of the present invention is shown. Similar elements in Fig. 5 have the same reference numerals. In addition, boxes with dashed lines are features on more advanced SoCs. In Fig.9, an interconnection unit(s) 902 is coupled to: an application processor 910 including a group of one or more cores 502A-N and shared cache unit(s) 506; a system agent unit 510; a bus control unit(s) 516; an integrated memory control unit(s) 514; a group of one or more media processors 920, which may include integrated graphics logic 508, an image processor 924 for providing still and / or video camera functionality, an audio processor 926 for providing hardware audio acceleration, and 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 external display devices.

[0102] Fig.10 illustrates a processor including a central processing unit (CPU) and a graphics processing unit (GPU) that may execute at least one instruction according to one embodiment. In one embodiment, an instruction to perform operations according to at least one embodiment may be executed by the CPU. In another embodiment, the instruction may be executed by the GPU. In yet another embodiment, the instruction may be executed by a combination of operations performed by the GPU and the CPU. For example, in one embodiment, an instruction may be received in accordance with one embodiment and decoded for execution on the GPU. However, one or more operations within the decoded instruction may be executed by a CPU and the result returned to the GPU for final retirement of the instruction.Conversely, in some embodiments, the CPU may operate as the primary processor and the GPU may operate as the coprocessor.

[0103] In some embodiments, instructions that take advantage of processors with highly parallel throughput may be executed by the GPU, while instructions that take advantage of the performance of processors that utilize low-pipeline architectures may be executed by the CPU. For example, graphics, scientific applications, financial applications, and other parallel workloads may take advantage of the performance of the GPU and be executed accordingly, while more sequential applications such as operating system kernels or application code may be better suited to the CPU.

[0104] 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, an SPI / SDIO controller 1035, a display device 1040, a high-resolution multimedia interface (HDMI) controller 1045, a MIPI controller 1050, a flash memory controller 1055, a double data rate (DDR) controller 1060, a security engine 1065, and an I 2 S / I 2 C interface (Integrated Chip-to-Chip / Integrated Circuit Interface) 1070. Other logic and circuits can be implemented in the processor of Fig. 10, which include more CPUs or GPUs and other peripheral interface control units.

[0105] One or more aspects of the present embodiment may be implemented by representative data stored on a machine-readable medium representing various logic within the processor that, when read by a machine, causes the machine to manufacture logic to perform the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible machine-readable medium ("tape") and delivered to various customers or manufacturing plants for loading into the manufacturing machines that actually produce the logic or processor. For example, IP cores, such as the Cortex™ processor family manufactured by ARM Holdings, Ltd.and Loongson IP cores 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.

[0106] Fig.11 shows a block diagram illustrating the development of IP cores according to one embodiment. Memory 1130 contains simulation software 1120 and / or hardware or software model 1110. In one embodiment, data representing the IP core design may be provided to memory 1130 via storage 1140 (e.g., hard disk), wired connection (e.g., Internet) 1150, or wireless connection 1160. The IP core information generated by the simulation tool and model may then be transferred to a manufacturing facility, where it may be manufactured by a third party to execute at least one instruction in accordance with at least one embodiment.

[0107] In some embodiments, one or more instructions may correspond to a first type or architecture (e.g., x86) and may be translated or emulated on a processor of a different type or architecture (e.g., ARM). Therefore, an instruction according to one embodiment may be executed on any processor or processor type, including ARM, x86, MIPS, a GPU, or another processor type or architecture.

[0108] Fig. 12 illustrates how an instruction of a first type is emulated by a processor of a different type according to one embodiment. In Fig.12, program 1205 includes some instructions that perform the same or substantially the same function as an instruction according to one embodiment. However, the instructions of program 1205 may be of a type and / or format that is different or incompatible with processor 1215, meaning that the instructions of the type in program 1205 may not be natively executed by processor 1215. However, with the aid of emulation logic 1210, the instructions of program 1205 are translated into instructions that can be natively executed by processor 1215. In one embodiment, the emulation logic is integrated into hardware. In another embodiment, the emulation logic is integrated into a tangible, machine-readable medium containing software to translate instructions of the type in program 1205 into the type that can be natively executed by processor 1215.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 includes the emulation logic, while in other embodiments, the emulation logic resides external to the processor and is provided by a third party. In one embodiment, the processor can load the emulation logic embedded in a tangible, machine-readable medium containing software by executing microcode or firmware included in or associated with the processor.

[0109] Fig.Figure 13 is a block diagram contrasting the use of a software instruction translation unit to translate binary instructions in a source instruction set into binary instructions in a target instruction set according to embodiments of the invention. In the illustrated embodiment, the instruction translation unit is a software instruction translation unit, although alternatively, the instruction translation unit may be implemented in software, firmware, hardware, or various combinations thereof. Fig.13 shows a program in a high-level language 1302 that may be compiled using an x86 compiler 1304 to produce x86 binary code 1306 that can be natively executed by a processor having at least one x86 instruction set core 1316. The processor having at least one x86 instruction set core 1316 represents any processor that can perform substantially the same functions as an Intel processor having at least one x86 instruction set core by compatibly executing or otherwise processing (1) a substantial portion of the instruction set of the Intel x86 instruction set core or (2) object code versions of applications or other software designed to run on an Intel processor having at least one x86 instruction set core to achieve substantially the same result as an Intel processor having at least one x86 instruction set core. The x86 compiler 1304 represents a compiler operable to compile x86 binary code 1306 (e.g.object code) that can be executed with or without additional link processing on the processor with at least one x86 instruction set core 1316. Similarly, . Fig.13, the program in the high-level language 1302 can be compiled using an alternative instruction set compiler 1308 to generate alternative instruction set binary code 1310 that can be natively executed by a processor without at least one x86 instruction set core 1314 (e.g., a processor with cores executing the MIPS instruction set from MIPS Technologies of Sunnyvale, CA, and / or executing the ARM instruction set from ARM Holdings of Sunnyvale, CA). The instruction translation unit 1312 is used to translate the x86 binary code 1306 into code that can be natively executed by the processor without an x86 instruction set core 1314. This translated code is likely not the same as the 1310 binary code of the alternative instruction set because an instruction translation unit for it is difficult to manufacture; however, the translated code will perform the general operation and consist of instructions from the alternative instruction set.Thus, instruction translation unit 1312 represents software, firmware, hardware, or a combination thereof that enables, through emulation, simulation, or any other process, a processor or other electronic device that does not have an x86 instruction set processor or core to execute x86 binary code 1306. . Fig.14 illustrates a flowchart for one embodiment of a process 1401 for efficiently implementing the Advanced Encryption Standard (AES) encryption / decryption standard. The process 1401 and other processes disclosed herein are performed by processing blocks that may include dedicated hardware or software or firmware operation codes that may be executed by general-purpose machines or by special-purpose machines, or by a combination of both. In one embodiment, a composite body GF((2 4 ) 2 ) with the irreducible polynomials x 4 + x 2 + x + 1 and x 2 + 2x + 0xE can be used for the AES inverse column merge transform.

[0110] In processing block 1411, a 128-bit input block containing 16 byte values is subjected to a logical exclusive-OR (XOR) operation with a round key. In processing block 1412, it is determined whether the process is encryption, in which case processing continues from point 1418, or whether the process is decryption, in which case the process continues to processing block 1413.

[0111] In processing block 1413, a field conversion circuit is used to convert each of the 16-byte values from a corresponding polynomial representation in GF(256) to another corresponding polynomial representation in the composite field GF((2 4 ) 2 ). For one embodiment of processing block 413, a polynomial representation in GF(256), [a7, a6, a5, a4, a3, a2, a1, a0], may be converted into a corresponding polynomial representation in the composite field GF((24 ) 2 ) ), [b7, b6, b5, b4, b3, b2, b1, b0], by multiplying each byte value by an 8-bit by 8-bit conversion matrix, which can be implemented by a series of XORs as follows: b0=a0⊕a2⊕a3⊕a4⊕a5⊕a6⊕a7, b1=a7, b2=a4⊕a5⊕a7, b3=a1⊕a3⊕a5⊕a6, b4=a4⊕a5⊕a6, b5=a1⊕a4⊕a5⊕a6, b6=a5⊕a7,b7=a2⊕a3⊕a4⊕a6⊕a7.

[0112] At this point, the 16 bytes can be considered a four-by-four block of bytes, having four rows and four columns. During processing of block 1414, it is determined whether the current round is the last / special round, in which case no inverse column shuffle is performed, or otherwise, during processing of block 1415, an inverse column shuffle circuit is used to perform an inverse column shuffle transformation in GF((2 4 ) 2) of the 16-byte values to calculate corresponding transformed polynomial representations in GF((2 4 ) 2 ). For one embodiment, the inverse column merge transform in GF((2 4 ) 2 ) of the 16-byte values as follows: Output=|0×200×400×090×880×880×200×400×090×090×880×200×400×400×090×880×20|⋅Input

[0113] It is noted that such a matrix multiplication on [a3, a2, a1, a0, b3, b2, b1, b0] in GF((2 4 ) 2 ) can be performed by calculating, in a first stage, the unique terms needed to perform the multiplications by the matrix constants in the expression for each result, and then summing the unique terms to produce each result. For example, the unique terms needed to calculate the above matrix multiplication are from the nibble [a3, a2, a1, a0]: (a3⊕a0)⊕a1,(a2⊕a1)⊕a3,(a2⊕a0)⊕a1,(a3⊕a2)⊕a0,a3⊕a1,(a3⊕a2)+(a1⊕a0).

[0114] The unique terms necessary to calculate the above matrix multiplication from the nibble [b3, b2, b1, b0] are: (b3⊕b2)⊕b1,(b2⊕b1)⊕b3,b3⊕b0,b3⊕b1,b1⊕b0(b3⊕b0)+(b1⊕b2).

[0115] In each case of what is determined in processing block 1414, a hard-wired permutation of the rows on the 16-byte values is performed in processing block 1416, corresponding to an inverse row shuffle transformation. In processing block 1417, a second array conversion circuit is used to convert each corresponding transformed polynomial representation into GF((2 4 ) 2 ) and also apply an affine inverse transformation to obtain a third corresponding polynomial representation in a finite field that is not GF((2 4 ) 2) is to be generated. In one embodiment of process 1401, the finite field that is not GF((2 4 ) 2 ), the composite field GF((2 2 ) 4 ). This embodiment is described below with reference to Fig. 2. In an alternative embodiment of process 1401, this new finite field is the original field GF(256). These embodiments are described below with reference to Fig. 3a and Fig. 3b described in more detail.

[0116] Continuing from point 1418, a multiplicative inverse circuit is used in processing block 120 to generate, for each of the third corresponding polynomial representations of the 16-byte values, a corresponding multiplicative inverse polynomial representation in this new finite field that is not GF((2 4 ) 2). In processing block 1421, it is determined whether the process is decryption, in which case round processing is terminated and a result is output to processing block 1426, or whether the process is encryption, in which case processing continues in processing block 1422.

[0117] In processing block 1422, circuitry is used to apply an affine transformation to each corresponding multiplicative inverse polynomial representation of the 16-byte values to produce a transformed corresponding polynomial representation in the new finite field that is not GF((2 4 ) 2). If this new finite field is not the original field GF(256), then further field transformation may be combined with the circuitry in block 1422 to transform each corresponding transformed polynomial representation back to the original field GF(256). Therefore, the polynomial representation for the remainder of process 1401 may be assumed to be in the original field GF(256).

[0118] In processing block 1423, a hard-wired permutation of the rows on the 16-byte values is performed, corresponding to a forward row shuffle transformation. In processing block 1424, it is determined whether the current round is the last / special round, in which case no column shuffle is performed, or otherwise, in processing block 1425, a forward column shuffle transformation is used to compute a forward column shuffle transformation in GF(256) of the 16-byte values to obtain corresponding transformed polynomial representations in GF(256). Note that because coefficients are relatively small in the forward column shuffle transformation in GF(256), no alternate field representation is used in processing block 1425. Finally, the round processing of process 1401 is completed and the 16-byte result is output in processing block 1426.

[0119] Fig. 15 illustrates a flowchart for one embodiment of a process 1501 for efficiently implementing a multiplicative inverse function of an AES-S-box. In one embodiment illustrated below, the composite field GF((2 2 ) 4 ) with the irreducible polynomial x 4 + x 3 + x 2 + 2, can be used for the S-box transformation.

[0120] Continuing from point 1418 of process 1401, at processing block 1518 it is determined whether the process is Encrypt, in which case processing continues with processing block 1519. Otherwise, if the process is Decrypt, a field conversion has already been performed in processing block 1417, and the third corresponding polynomial representations of the 16-byte values are in the composite field GF((2 2 ) 4). For one embodiment of processing block 1417, an affine inverse transformation may be applied, and a polynomial representation in the composite field GF((2 4 ) 2 ), [a7, a6, a5, a4, a3, a2, a1, a0], can be converted into a speaking polynomial representation in the composite field GF((2 2 ) 4 ), [b7, b6, b5, b4, b3, b2, b1, b0], can be implemented by multiplying each byte value by an 8-bit by 8-bit conversion matrix and XORs of some constants (i.e., bitwise inversions), which can be implemented by a series of XORs as follows: ¬b0=a3⊕a5⊕a7, b1=a1⊕a2⊕a3⊕a4, b2=a0⊕a2⊕a4⊕a5⊕a6, b3=a0⊕a1⊕a2⊕a4⊕a5⊕a6,¬b4=a1⊕a6 b5=a0⊕a1⊕a2⊕a3⊕a5⊕a6⊕a7, ¬b6=a0⊕a5⊕a6, b7=a0⊕a1⊕a2⊕a3⊕a4⊕a6.

[0121] In processing block 1519, a field translation is required for the encryption process, and thus a translation circuit is used to translate each of the 16-byte values from a corresponding polynomial representation in GF(256) to a corresponding polynomial representation in the composite field GF((2 2 ) 4 ). For one embodiment of processing block 1519, a polynomial representation in GF(256), [a7, a6, a5 a4, a3, a2, a1, a0], may be converted into a corresponding polynomial representation in the composite field GF((2 2 ) 4 )), [b7, b6, b5, b4, b3, b2, b1, b0], can be implemented by multiplying each byte value by an 8-bit by 8-bit conversion matrix, which can be implemented by a series of XORs as follows: b0=a0⊕a1⊕a6, b1=a1⊕a4⊕a6, b2=a5⊕a6⊕a7, b3=a3⊕a4, b4=a1⊕a2⊕a3⊕a4⊕a5, b5=a3⊕a4⊕a5⊕a7, b6=a2⊕a5⊕a6, b7=a3⊕a7.

[0122] In processing block 1520, an inverting circuit is used to calculate for each of the polynomial representations in GF((2 2 ) 4 ) of the 16-byte values each have a multiplicative inverse polynomial representation GF((2 2 ) 4 ). One embodiment includes an input corresponding to a polynomial representation in the composite field GF((2 2 ) 4 )), [a, b, c, d], and a multiplicative inverse function, [A, B, C, D], as follows: (a⊕c⊕d)⋅A⊕(b⊕c)⋅B⊕(a⊕b)⋅C⊕a⋅D=0 (2⋅a⊕b⊕c)⋅A⊕(a⊕b⊕d)⋅B⊕(a⊕c)⋅C⊕b⋅D=0 (2⋅a⊕2⋅b)⋅A⊕(2⋅a)⋅B⊕d⋅C⊕c⋅D=0 (2⋅b⊕2⋅c)⋅A⊕(2⋅a⊕2⋅b)⋅B⊕(2⋅a)⋅C⊕d⋅D=1 where ⊕ and ‚.'' are the GF(2 2 ) additions and multiplications, respectively. The solution is: A = Δ -1 · Δ a , B = Δ -1 · Δ b , C = Δ -1 · Δ c , D = Δ -1 · Δd , where the determinant Δ is given by: Δ=|a⊕c⊕db⊕ca⊕ba2⋅a⊕b⊕ca⊕b⊕da⊕cb2⋅a⊕2⋅b2⋅adc2⋅b⊕2⋅c2⋅a⊕2⋅b2⋅ad| and the determinants Δ a , Δ b , Δ c and Δ d from Δ by replacing the first, second, third and fourth columns of Δ by {0, 0, 0, 1} respectively. It is again pointed out that such calculations in GF(2 2 ) by extending the determinant calculation, calculating the unique terms in hardware such as a 2 , b 2 , a 3 , 3 b 2 etc. and the unique sums of required terms and then summing the special term combinations to produce the necessary results.

[0123] In processing block 1521, it is determined whether the processing is decryption, in which case processing continues with processing block 1522. In processing block 1522, another field conversion circuit is used to convert each of the 16-byte values from a corresponding polynomial representation in the composite field GF((2 2 ) 4 ) into a corresponding polynomial representation in GF(256). For one embodiment of processing block 1522, a polynomial representation may be stored in the composite field GF((2 2 ) 4 )), [a7, a6, a5, a4, a3, a2, a1, a0], into a corresponding polynomial representation of GF(256), [b7, b6, b5, b4, b3, b2, b1, b0], by multiplying each byte value by an 8-bit by 8-bit conversion matrix, which can be implemented by a series of XORs as follows: b0=a0⊕a3⊕a4⊕a6, b1=a2⊕a4⊕a5⊕a6, b2=a1⊕a2⊕a4⊕a7, b3=a1⊕a4⊕a6, b4=a1⊕a3⊕a4⊕a6, b5=a1⊕a3⊕a4⊕a5⊕a6⊕a7, b6=a2⊕a3⊕a5, b7=a1⊕a4⊕a6⊕a7.

[0124] Otherwise, if the process is Encrypt, processing continues with processing block 1421 of process 1401. As explained with reference to processing block 1422 of process 1401, the circuitry used to apply an affine transformation to the 16 bytes in processing block 1422 may be combined with the field translation circuitry of this embodiment to convert the 16-byte values from polynomial representations to GF((2 2 ) 4 ) into corresponding polynomial representations in GF(256). For one embodiment of processing block 1422, an affine transformation may be applied, and a polynomial representation in the composite field GF((2 2 ) 4)), [a7, a6, a3, a4, a3, a2, a1, a0], can be converted into a speaking polynomial representation in field GF(256), [b7, b6, b5, b4, b3, b2, b1, b0], by multiplying each byte value by an 8-bit by 8-bit conversion matrix and XORing it with some constants (i.e., bitwise inversions), which can be implemented by a series of XORs as follows: ¬b0=a0⊕a1⊕a2, ¬b1=a0⊕a3⊕a5, b2=a0⊕a2⊕a6, b3=a0⊕a1⊕a3⊕a4⊕a5, b4=a0⊕a1⊕a4⊕a5⊕a7, ¬b5=a4, ¬b6=a3⊕a6, b7=a2⊕a3.

[0125] Fig.16A illustrates a diagram for one embodiment of an apparatus 1601 for executing an affine mapping instruction for an affine transformation to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. In some embodiments, an apparatus 1601 may be duplicated sixteen times, with each apparatus 1601 including hardware processing blocks for efficiently implementing an affine transformation on a 128-bit block containing 16-byte values, where each byte has a polynomial representation in GF(256). In other embodiments of an affine mapping instruction (or microinstruction), an element size may also be specified, and / or the number of duplications of a device 1601 may be selected to implement an affine transformation on a 128-bit block, or a 256-bit block, or a 512-bit block, etc. Embodiments of the device 1601 may be part of a pipeline 400 (e.g.,Execution stage 416) or part of a core 490 (e.g., execution unit(s) 462) for executing an affine mapping instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of apparatus 1601 may be coupled to a decode stage (e.g., decode 406) or decoder (e.g., decode unit 440) to decode an instruction for an affine transformation to GF(256). In some embodiments, an affine mapping instruction may be implemented by microinstructions (or micro-operations, micro-ops, or uops) -- for example, a finite-field matrix-vector multiplication microinstruction followed by a finite-field vector addition (XOR) microinstruction. For example, embodiments of the device 1601 may be implemented with SIMD vector registers (e.g.,physical register file unit(s) 458) comprising a variable majority of m variable-size data fields for storing values of a variable plurality of m variable-size data elements. Some embodiments of the affine mapping instruction, to provide general-purpose GF(256) SIMD affine transformation functionality, specify a source data operand set of elements 1612, an operand of the transformation matrix 1610, and an operand of the translation vector 1614. One or more execution units (e.g., execution unit(s) 462), in response to the decoded affine mapping instruction, perform an affine SIMD transformation by applying the operand of the transformation matrix 1610 to each element 1612 of the source data operand set (e.g.,in a 128-bit block of 16-byte elements) by eight bitwise ANDs 1627-1630 of the GF(256)-byte multiplier field of processing block 1602 and applying the operand of the translation vector 1614 by eight 9-input XORs 1637-1630 of the GF(256)-bit adder field of processing block 1603 to each transformed element of the source data operand set. An affine transformed result element 1618 for each element 1612 of the source data operand set of the affine mapping instruction is stored in a SIMD destination register (e.g., physical register file unit(s) 458).

[0126] Fig.16B illustrates a diagram for one embodiment of an apparatus 1605 for executing an affine inverse instruction for an affine transformation followed by computing a multiplicative inverse function of the result to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of the apparatus 1605 may be part of a pipeline 400 (e.g., execution stage 416) or part of a core 490 (e.g., execution unit(s) 462) for executing an affine inverse instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of the apparatus 1605 may be coupled to a decoding stage (e.g., decode 406) or a decoder (e.g., decode unit 440) to decode an instruction for an affine transform and inverse function in GF(256).In some embodiments, an affine inversion instruction may be implemented by micro-instructions (or micro-operations, micro-ops, or uops) -- for example, by an affine micro-instruction. Fig. followed by a finite-field multiplicative inverse microinstruction 1604. In alternative embodiments, an affine inverse instruction may be implemented by different microinstructions—for example, a finite-field matrix-vector multiplication microinstruction followed by a byte-by-byte broadcast microinstruction, a finite-field vector addition (XOR) microinstruction, and a finite-field multiplicative inverse microinstruction.

[0127] Embodiments of the apparatus 1605 may be coupled to SIMD vector registers (e.g., physical register file(s) 458) comprising a variable plurality of m variable-size data fields for storing values of a variable plurality of m variable-size data elements. Some embodiments of the affine inverse instruction, to provide general-purpose GF(256) SIMD affine transformation functionality followed by computing a multiplicative inverse function of the result, specify a source data operand set of elements 1612, an operand for the transformation matrix 1610, an operand for the translation vector 1614, and optionally a normalized irreducible polynomial. One or more execution units (e.g.,The execution unit(s) 462, in response to the decoded affine inversion instruction, perform an affine SIMD transformation by applying the operand of the transformation matrix 1610 to each element 1612 of the source data operand set (e.g., in a 128-bit block of 16-byte elements) through eight bitwise ANDs 1627-1620 of the GF(256) byte multiplier array of processing block 1602 and applying the operand of the translation vector 1614 through eight 9-input XORs 1637-1630 of the GF(256) bit adder array of processing block 1603 to each transformed element of the source data operand set. Note that this point in the computation may correspond to point 1418 of process 1403. A multiplicative inverse element 1648 of the finite field modulo an irreducible polynomial is computed by the multiplicative inverse unit 1640 from the transformed affine result element 1618 for each element 1612 of the source data operand set.The result elements 1648 of the multiplicative inverse function for each affine transformed result element 1618 of the affine inverse instruction are stored in a SIMD destination register (e.g., in physical register file unit(s) 458).

[0128] It should be noted that some embodiments of an affine reverse instruction may be useful to perform a process such as process 1403. Other embodiments may be useful to perform a process such as process 1402.

[0129] Fig.16C illustrates a diagram for an alternative embodiment of an apparatus 1606 for executing an inverse affine instruction to compute an inverse multiplicative function followed by an affine transformation of the result to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of the apparatus 1606 may be part of a pipeline 400 (e.g., execution stage 416) or part of a core 490 (e.g., execution unit(s) 462) for executing an affine inverse instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of the apparatus 1606 may be coupled to a decoding stage (e.g., decode 406) or a decoder (e.g., decode unit 440) to decode an instruction for an inverse and affine transformation into GF(256).In some embodiments, an inverse affine instruction may be implemented by micro-instructions (or micro-operations, micro-ops, or uops) -- for example, a multiplicative inverse micro-instruction 1604 for a finite field followed by an affine mapping micro-instruction 1601. In alternative embodiments, an inverse affine instruction may be implemented by different micro-instructions - for example, a multiplicative inverse micro-instruction for a finite field followed by a matrix-vector multiplication micro-instruction for a finite field and a vector-scalar translation micro-instruction for a finite field (e.g., broadcast and XOR).

[0130] Embodiments of the apparatus 1606 may be coupled to SIMD vector registers (e.g., physical register file(s) 458) comprising a variable plurality of m variable-size data fields for storing values of a variable plurality of m variable-size data elements. Some embodiments of the inverse affine instruction, to provide general-purpose GF(256) SIMD computation of an inverse multiplicative function followed by affine transformation functionality, specify a source data operand set of elements 1612, an operand of a transformation matrix 1610, an operation of a translation vector 1614, and optionally a normalized irreducible polynomial. In processing block 1604, one or more execution units (e.g.,Execution unit(s) 462) in response to the decoded affine inversion instruction, a binary multiplicative inversion SIMD element 1616 for a finite field modulo an irreducible polynomial by the multiplicative inversion unit 1640 for each element 1612 of the source data operand set. The one or more execution units then perform an affine SIMD transformation by applying the operand of transformation matrix 1610 to each multiplicative inverse element 1616 of element 1612 of the source data operand set (e.g., in a 128-bit block of 16-byte elements) through eight bitwise ANDs 1627-1620 of the GF(256) byte multiplier array of processing block 1602 and applying the operand of translation vector 1614 through eight 9-input XORs 1637-1630 of the GF(256) bit adder array of processing block 1603 to each transformed inverse element of the source data operand set.An affine transformed result element 1638 for each multiplicative inverse element 1616 of element 1612 of the source data operand set of the affine inverse mapping instruction is stored in a SIMD destination register (e.g., physical register file unit(s) 458).

[0131] Fig.17A illustrates a diagram for one embodiment of an apparatus 1701 for executing a finite field multiplicative inverse instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. In some embodiments, an apparatus 1701 may be duplicated sixteen times, with each apparatus 1701 including hardware processing blocks for efficiently implementing an AES S-box multiplicative inverse function on a 128-bit block containing 16-byte values, where each byte has a polynomial representation in GF(256). In other embodiments of a finite field multiplicative inverse instruction (or microinstruction), an element size may also be specified and / or the number of duplications of a device 1701 may be selected to implement a finite field multiplicative inverse function on a 128-bit block, or a 256-bit block, or a 512-bit block, etc.Embodiments of apparatus 1701 may be part of a pipeline 400 (e.g., execution stage 416) or part of a core 490 (e.g., execution unit(s) 462) for executing a finite field multiplicative inverse instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of apparatus 1701 may be coupled to a decode stage (e.g., decode 406) or a decoder (e.g., decode unit 440) to decode a multiplicative inverse function instruction in GF(256). In apparatus 1701, we consider each byte x input from point 1418 of process 1401; therefore, apparatus 1701 begins by accessing a source data operand set containing x.Processing blocks 1711-1717 comprise a byte slice of polynomial power generating circuitry to compute, for each of the 16-byte values, byte values having polynomial representations in GF(256) corresponding to the powers x. 2 , x 4 , x 8 , x 16 , x 32 , x 64 and x 128 the polynomial representation of their respective byte values x. Processing blocks 1718-1720 and 1728-1730 comprise a byte slice of a multiplier circuit to multiply together in GF(256) the byte values corresponding to powers of the polynomial representations for each of the 16-byte values, respectively, to produce 16-byte values, each of which has a polynomial representation in GF(256) corresponding to the multiplicative inverse x -1 = x 254, of their respective byte value x. These 16 multiplicative inverse byte values are then stored (e.g., in physical register file unit(s) 458) or output to processing block 1421 of process 1401, where an affine transformation circuit (e.g., 1601) is optionally used in processing block 1422 to apply an affine transformation, depending on whether process 1401 is performing encryption or decryption.

[0132] Fig.Figure 17B illustrates a diagram for an alternative embodiment of an apparatus 1702 for executing a finite field multiplicative inverse instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. In some embodiments, an apparatus 1702 may be duplicated sixteen times, with each apparatus 1702 including hardware processing blocks for efficiently implementing an AES S-box multiplicative inverse function on a 128-bit block containing 16-byte values, where each byte has a polynomial representation in GF(256). In other embodiments of a finite field multiplicative inverse instruction (or microinstruction), an element size may also be specified and / or the number of duplications of a device 1702 may be chosen to implement a multiplicative inverse function on a 128-bit block, or a 256-bit block, or a 512-bit block, etc.Embodiments of apparatus 1702 may be part of a pipeline 400 (e.g., execution stage 416) or part of a core 490 (e.g., execution unit(s) 462) for executing a finite field multiplicative inversion instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of apparatus 1702 may be coupled to a decode stage (e.g., decode 406) or a decoder (e.g., decode unit 440) to decode an instruction for a multiplicative inversion instruction in GF(256). In apparatus 1702, we again consider each byte x input from point 1418 of process 1401, therefore apparatus 1702 begins by accessing a source data operand set containing x. Note that item 1418 of process 1401 may represent the output of an affine transformation circuit (e.g., 1601) or an affine mapping instruction in processing block 1417.Processing blocks 1721-1727 include a byte slice of polynomial power generating circuitry to compute, for each of the 16-byte values, byte values having polynomial representations in GF(256) corresponding to the powers x. 6 , x 24 , x 96 and x 128 correspond to the polynomial representation of their respective byte values x.

[0133] Processing blocks 1728-1730 comprise a byte slice of multiplier circuitry to collectively multiply in GF(256) the byte values corresponding to powers of the polynomial representations for each of the 16-byte values, respectively, to produce 16-byte values, each of which has a polynomial representation in GF(256) corresponding to the multiplicative inverse x -1 = x 254, of their respective byte value x. The 16 multiplicative inverse byte values are stored (e.g., in physical register file unit(s) 458) or output to processing block 1421 of process 1401, where an affine transformation circuit (e.g., 1601) is optionally used in processing block 122 to apply an affine transformation, depending on whether process 1401 is performing encryption or decryption.

[0134] Fig.17C illustrates a diagram for another alternative embodiment of an apparatus 1703 for executing a finite field multiplicative inverse instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. In some embodiments, an apparatus 1703 may be duplicated sixteen times, with each apparatus 1703 including hardware processing blocks for efficiently implementing a finite field multiplicative inverse function on a 128-bit block containing 16-byte values, where each byte has a polynomial representation in GF(256). In other embodiments of a finite field multiplicative inverse instruction (or microinstruction), an element size may also be specified and / or the number of duplications of a device 1703 may be chosen to implement a multiplicative inverse function on a 128-bit block, or a 256-bit block, or a 512-bit block, etc.Embodiments of apparatus 1703 may be part of a pipeline 400 (e.g., execution stage 416) or part of a core 490 (e.g., execution unit(s) 462) for executing a finite field multiplicative inverse instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of apparatus 1703 may be coupled to a decode stage (e.g., decode 406) or a decoder (e.g., decode unit 440) to decode a multiplicative inverse function instruction in GF(256).

[0135] Embodiments of apparatus 1703 may be coupled to SIMD vector registers (e.g., physical register file(s) 458) comprising a variable plurality of m variable-size data fields for storing values of a variable plurality of m variable-size data elements. Some embodiments of the finite-field multiplicative inverse instruction, to provide general-purpose GF(256) SIMD multiplicative inverse functionality, specify a source data operand set of elements 1710 and a normalized irreducible polynomial 1740. One or more execution units (e.g., execution unit(s) 462), in response to the decoded finite-field multiplicative inverse instruction, compute a binary finite-field multiplicative SIMD inverse function modulo the irreducible polynomial for each element 1710 of the source data operand set.Some embodiments of apparatus 1703 perform the multiplicative inverse operation of the finite field in a composite field GF((2. 4 ) 2 ). Each element 1710 of the source data operand set is mapped to the composite field GF((2 4 ) 2 ) in processing block 1734, which represents 4-bit body elements z H 1735 and z L 1736. For one embodiment, the inverse body element z L -1 1746 calculated as follows: (1) the body elements z H 1735 and z L 1736 are added in the composite field (bitwise XOR 1737); (2) the field elements z H 1735 and the output of the bitwise XOR 1737 are multiplied modulo an irreducible polynomial p in processing block 1739. In one embodiment, the polynomial p = z 4 + z 3+ 1 is used, but in alternative embodiments, other irreducible polynomials of degree 4 can be used. Continue with the calculation of the inverse field element z L -1 1746: (3) the body element z H 1735 is squared and multiplied modulo p by a hexadecimal value, 8, in processing block 1738, the result of which is added (bitwise XOR 1741) to the output of processing block 1739 in the composite body; (4) the inverse of the output of the bitwise XOR 1741 is calculated in processing block 1742 and (5) modulo p with body elements z L 1736 in processing block 1744 to obtain the inverse body element z L -1 1746. For one embodiment, the inverse body element z H -11745 is calculated as follows: steps (1) through (4) as described above; and (5) the output of processing block 1742 is multiplied modulo p by body elements z H 1735 in processing block 1743 to obtain the inverse body element z H -1 1745. Each pair of 4-bit body elements z H -1 1745 and z L -1 1746 are then inversely mapped from the composite field GF((2 4 ) 2 ) in processing block 1747 to generate a multiplicative inversion of the result element 1750 in GF(256). A multiplicative inversion of the result element 1750 for each element 1710 of the source data operand set of the finite field multiplicative inversion instruction is finally stored in a SIMD destination register (e.g., physical register file unit(s) 458).

[0136] Fig.18A illustrates a diagram of one embodiment of an apparatus 1801 for executing a special modulo reduction instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. In the currently illustrated example, the special modulo polynomial 1811B is p = x 8 + x 4 + x 3+ x + 1 in GF(256). In some embodiments, a device 1801 may be duplicated sixteen times, with each device 1801 including hardware processing blocks for efficiently implementing a special modulo reduction on two 128-bit blocks (or one 256-bit block) containing 16 two-byte values to produce one 128-bit block containing 16-byte values, each of the resulting 16-byte values having a polynomial representation in GF(256). Embodiments of the apparatus 1801 may be part of a pipeline 400 (e.g., execution stage 416) or part of a core 490 (e.g., execution unit(s) 462) for executing a special modulo reduction instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of the apparatus 1801 may be provided with a decoding stage (e.g., decode 406) or a decoder (e.g.,Decoding unit 440) to decode an instruction for a special modulo reduction in GF(256).

[0137] Embodiments of apparatus 1801 may be coupled to SIMD vector registers (e.g., physical register file(s) 458) comprising a variable plurality of m variable-size data fields for storing values of a variable plurality of m variable-size data elements. Some embodiments of the special modulo reduction instruction, to provide general-purpose GF(256) SIMD modulo reduction functionality, specify a source data operand set of elements 1810 and a normalized irreducible polynomial 1811B. One or more execution units (e.g., execution unit(s) 462), in response to the decoded modulo reduction instruction, compute a SIMD reduction of the binary finite field modulo the irreducible polynomial for each element 1810 of the source data operand set. An element 1810 of the source data operand set that has a two-byte value is called q H 1828 and q L1820 is input to processing block 1821. Some embodiments of device 1801 perform a 12-bit operation in processing block 1825 in processing block 1821 that is equivalent to: T←qL⊕(qH<<4)⊕(qH<<3)⊕(qH<<1)⊕qH.

[0138] A result element, T, from processing block 1825, which has a partially reduced 12-bit value, is referred to as T H 1838 and T L 1830 is input to processing block 1831. Some embodiments of device 1801 perform an 8-bit operation in processing block 1835 in processing block 1831, which is also equivalent to: q mod p←TL⊕(TH<<4)⊕(TH<<3)⊕(TH<<1)⊕TH.

[0139] Note that in XOR operations, zero inputs (0 inputs) are eliminated, thereby further reducing the logical complexity of device 1801. A special modulo reduction result element 1850 for each element 1810 of the source data operand set of the special modulo reduction instruction is stored in a SIMD destination register (e.g., a physical register file unit(s) 458).

[0140] Fig. 18B illustrates a diagram of an alternative embodiment of an apparatus 1802 for executing a special modulo reduction instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. In the currently illustrated example, the special modulo polynomial 1811B is also p = x 8 + x 4 + x 3+ x + 1 in GF(256). Note that similar techniques can also be applied to create another special modulo reduction instruction (or micro-instruction) for other modulo polynomials, e.g., f5 = x 8 + x 7 + x 6 + x 5 + x 4 + x 2+ 1 in GF(256), as used in SMS4, the block cipher of the Chinese national standard for wireless LAN WAPI (Wired Authentication and Privacy Infrastructure). In some embodiments, a device 1802 may be duplicated sixteen times, with each device 1802 implementing hardware processing blocks for efficiently implementing a special modulo reduction on two 128-bit blocks (or one 256-bit block) containing 16 two-byte values to produce one 128-bit block containing 16-byte values, where each of the resulting 16-byte values has a polynomial representation in GF(256). Embodiments of the apparatus 1802 may be part of a pipeline 400 (e.g., execution stage 416) or part of a core 490 (e.g.,Execution unit(s) 462) for executing a special modulo reduction instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of apparatus 1802 may be coupled to a decoding stage (e.g., decode 406) or a decoder (e.g., decode unit 440) to decode an instruction for a special modulo reduction in GF(256).

[0141] Embodiments of apparatus 1802 may be coupled to SIMD vector registers (e.g., physical register file(s) 458) comprising a variable plurality of m variable-size data fields for storing values of a variable plurality of m variable-size data elements. Some embodiments of the special modulo reduction instruction, to provide general-purpose multiplicative GF(256) SIMD modulo reduction functionality, specify a source data operand set of elements 1810 and a normalized irreducible polynomial 1811B. One or more execution units (e.g., execution unit(s) 462), in response to the decoded modulo reduction instruction, compute a SIMD reduction of the binary finite field modulo the irreducible polynomial for each element 1810 of the source data operand set. An element 1810 of the source data operand set having a two-byte value is input to processing block 1861 as q[15:8] 1828 and q[7:0] 1820.Some embodiments of apparatus 1802 perform a logical operation in XOR logic gates 1867-1860 in processing block 1861 that is equivalent to:. q0 mod p=q0⊕q8⊕q12⊕q13, q1 mod p=q1⊕q8⊕q9⊕q12⊕q14, q2 mod p=q2⊕q9⊕q10⊕q13, q3 mod p=q3⊕q8⊕q10⊕q11⊕q12⊕q13⊕q14, q4 mod p=q4⊕q8⊕q9⊕q12⊕q14, q5 mod p=q5⊕q9⊕q10⊕q12, q6 mod p=q6⊕q10⊕q11⊕q13, q7 mod p=q7⊕q11⊕q12⊕q14.

[0142] A special modulo reduction result element (q mod p) 1850 for each element 1810 of the source data operand set of the special modulo reduction instruction is stored in a SIMD destination register (e.g., a physical register file unit(s) 458).

[0143] Fig.18C illustrates a diagram for another embodiment of an apparatus 1803 for executing an instruction for executing a special AES Galois Counter Mode Modulo Reduction (GCM Modulo Reduction) instruction to calculate cryptographic GF(2 128 )-SIMD arithmetic functionality. In the currently presented example, the special modulo polynomial 1887 p = x 128 + x 7 + x 2 + x + 1 in GF(256). Embodiments of the apparatus 1803 may be part of a pipeline 400 (e.g., execution stage 416) or part of a core 490 (e.g.,

[0144] Execution unit(s) 462) to execute a special modulo reduction instruction to obtain cryptographic GF(2 128)-SIMD arithmetic functionality. Embodiments of the apparatus 1803 may be coupled to a decoding stage (e.g., decoding 406) or a decoder (e.g., decoding unit 440) to provide an instruction for a specific modulo reduction in GF(2 128 ) to decode.

[0145] Embodiments of the apparatus 1803 may be coupled to SIMD vector registers (e.g., physical register file(s) 458) comprising a variable plurality of m variable-size data fields for storing values of a variable plurality of m variable-size data elements. Some embodiments of the special instruction to perform an AES-GCM modulo reduction in GF(2 128) functionality, specify a source data operand set of elements 1813 and a normalized irreducible polynomial 1887. One or more execution units (e.g., execution unit(s) 462), in response to the decoded finite field modulo reduction instruction, compute a multiplicative SIMD reduction of the binary finite field modulo the irreducible polynomial for each element 1813 of the source data operand set.

[0146] An element 1813 of a source data operand set having a 32-bit value is input to processing block 1871. Some embodiments of apparatus 1803 perform, in processing block 1871, a non-bit-reflected operation on a non-bit-reflected reduction polynomial that is equivalent to a bit-reflected modulo reduction of a bit-reflected product, as follows: [X3,X2,X1,X0]=q[255:0]<<1; A=X0<<63; B=X0<<62; C=X0<<57; D=X1⊕A⊕B⊕C; [E1,E0]=[D,X0]>>1; [F1,F0]=[D,X0]>>2; [G1,G0]=[D,X0]>>7; q[127:64]=X3⊕D⊕E1⊕F1⊕G1(mod p); q[63:0]=X2⊕X0⊕E0⊕F0⊕G0(mod p).

[0147] Accordingly, equation (i) is obtained by a shift 1870 of element 1813 to produce [X3, X2, X1, X0] 1872. Equations (ii) are obtained by shifts 1873-1875. Equation (iii) is obtained by processing block 1876. Equations (iv) are obtained by shifts 1877-1879. Equation (v) is obtained by processing block 1885, and equation (vi) is obtained by processing block 1880. A special modulo reduction result element (q mod p) 1853 for each element 1813 of the source data operand set of the special modulo reduction instruction is stored in a SIMD destination register (e.g., a physical register file unit(s) 458).

[0148] Fig.18D illustrates a diagram for one embodiment of an apparatus 1804 for executing a modulo reduction instruction to provide general-purpose GF(2)-SIMD finite-field cryptographic binary arithmetic functionality. In the presently illustrated example, a particular modulo polynomial p s be selected from the special modulo polynomials for which modulo reduction is provided by the instruction (or micro-instruction), for example p0, p1, ... p n. In some embodiments with t = 8, a device 1804 may be duplicated sixteen times, with each device 1804 implementing hardware processing blocks for efficiently implementing a special modulo reduction on two 128-bit blocks (or one 256-bit block) containing 16 two-byte values to produce one 128-bit block containing 16-byte values, where each of the resulting 16-byte values has a polynomial representation in GF(256), or alternatively in a composite field, e.g., GF((2 4 ) 2 ), or GF((2 2 ) 4), etc. In other embodiments of a modulo reduction instruction (or microinstruction), a size, t, may also be specified, and / or the number of duplications of a device 1804 may be selected to produce a 128-bit block, or a 256-bit block, or a 512-bit block, etc. Embodiments of the device 1804 may be part of a pipeline 400 (e.g., execution stage 416) or part of a core 490 (e.g., execution unit(s) 462) for executing a modulo reduction instruction to implement general-purpose cryptographic GF(2 t )-SIMD arithmetic functionality of the binary finite field. Embodiments of the apparatus 1804 may be coupled to a decoding stage (e.g., decoding 406) or a decoder (e.g., decoding unit 440) to provide an instruction for a modulo reduction in a binary finite field GF(2 t ) or alternatively in a composite body e.g. GF((2 u ) v), with t = u + v, to decode.

[0149] Fig.19A illustrates a diagram for one embodiment of an apparatus 1901 for executing a binary finite field multiplication instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. In some embodiments, an apparatus 1901 may be duplicated sixteen times, with each apparatus 1901 including hardware processing blocks for efficiently implementing a binary finite field multiplicative inverse function on two 128-bit blocks, each containing 16-byte values, where each byte has a polynomial representation in GF(256).In other embodiments of a binary finite field multiplication instruction (or micro-instruction), an element size may also be specified, and / or the number of duplications of a device 1901 may be selected to implement a binary finite field multiplication across two 128-bit blocks, or two 256-bit blocks, or two 512-bit blocks. Embodiments of the device 1901 may be part of a pipeline 400 (e.g., execution stage 416) or part of a core 490 (e.g., execution unit(s) 462) for executing a binary finite field multiplication instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of the apparatus 1901 may be coupled to a decoding stage (e.g., decoding 406) or a decoder (e.g., decoding unit 440) to decode an instruction for a multiplication of the finite field in GF(256).

[0150] Embodiments of apparatus 1901 may be coupled to SIMD vector registers (e.g., physical register file(s) 458) comprising a variable plurality of m variable-size data fields for storing values of a variable plurality of m variable-size data elements. Some embodiments of the binary finite field multiplication instruction, to provide general-purpose GF(256) SIMD computing of a binary finite field multiplication functionality, specify two source data operand sets of elements 1910 and 1912 and a normalized irreducible polynomial. In processing block 1902, one or more execution units (e.g., execution unit(s) 462), in response to the decoded binary finite field multiplication instruction, compute a carry-free 8-by-8-bit SIMD multiplication to generate a 15-bit product element 1915 and a reduced product 1918 modulo a selected (e.g.,by the selection unit 1916) to produce an irreducible polynomial by the modulo reduction unit 1917 for each pair of elements 1910 and 1912 of the source data operand sets. A reduced product result 1918 for each multiplication of a binary finite field of a pair of elements 1910 and 1912 of the source data operand sets is stored in a SIMD destination register (e.g., in physical register file unit(s) 458).

[0151] Fig.19B illustrates a diagram of an alternative embodiment of an apparatus 1903 for executing a binary finite field multiplication instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. In some embodiments, an apparatus 1903 may be duplicated twice, with each apparatus 1903 including hardware processing blocks for efficiently implementing a binary finite field multiplication on two 128-bit blocks, each containing 16-byte values, where each byte has a polynomial representation in GF(256).In other embodiments of a binary finite field multiplication instruction (or micro-instruction), an element size may also be specified, and / or the number of duplications of a device 1903 may be selected to implement a binary finite field multiplication across two 128-bit blocks, or two 256-bit blocks, or two 512-bit blocks. Embodiments of the device 1903 may be part of a pipeline 400 (e.g., execution stage 416) or part of a core 490 (e.g., execution unit(s) 462) for executing a binary finite field multiplication instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. Embodiments of the apparatus 1903 may be coupled to a decoding stage (e.g., decoding 406) or a decoder (e.g., decoding unit 440) to decode an instruction for a multiplication of the finite field in GF(256).

[0152] Embodiments of apparatus 1903 may be coupled to SIMD vector registers (e.g., physical register file(s) 458) comprising a variable plurality of m variable-size data fields for storing values of a variable plurality of m variable-size data elements. Some embodiments of the binary finite field multiplication instruction, to provide general-purpose GF(256) SIMD computing of a binary finite field multiplication functionality, specify two source data operand sets, e.g., 1920 and 1922, and a normalized irreducible polynomial p. In each processing block 1902 of array 1925, one or more execution units (e.g., execution unit(s) 462), in response to the decoded binary finite field multiplication instruction, compute a carry-free 8-by-8 SIMD multiplication to produce a product element 1915 and a reduced product 1918 modulo a selected (e.g.,by the selection unit 1916) irreducible polynomial by a modulo reduction unit 1917 for each pair of elements of the source data operand sets 1920 and 1922. A result of the reduced product set 1928 for the SIMD multiplication of the binary finite field of the source data operand sets 1920 and 1922 is stored in a SIMD destination register (e.g., in physical register file unit(s) 458).

[0153] Fig.20A illustrates a flow diagram for one embodiment of a process 2001 for executing an affine mapping instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. The process 2001 and other processes disclosed herein are executed by processing blocks that may include dedicated hardware, software, or firmware operation codes that may be executed by general-purpose machines, by special-purpose machines, or by a combination of both.

[0154] In processing block 2011, a processor instruction for an affine mapping for an affine SIMD transformation in a finite field is decoded. In processing block 2016, decoding the affine mapping instruction optionally generates micro-instructions, e.g., a first micro-instruction for a finite field matrix-vector multiplication 1602 and a second micro-instruction for a finite field vector addition (or XOR) 1603. In processing block 2021, a source data operand set of elements is accessed. In processing block 2031, a transformation matrix operand is accessed. In processing block 2041, a translation vector operand is accessed. In processing block 2051, the transformation matrix operand is applied to each element of the source data operand set. In processing block 2061, the translation vector operand is applied to each transformed element of the source data operand set.In processing block 2081, a determination is made as to whether or not the processing of each element of the source data operand set has been completed. If not, the affine SIMD transformation processing performs a new iteration, beginning in processing block 2051. Otherwise, in processing block 2091, a result of the affine SIMD transformation is stored in a SIMD destination register.

[0155] Fig.20B illustrates a flow diagram for one embodiment of a process 2002 for executing a finite-field multiplicative inverse instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. In processing block 2012, a processor instruction for the multiplicative inverse function is decoded for a SIMD multiplicative inverse function in a finite field. In processing block 2016, decoding the multiplicative inverse instruction optionally generates micro-instructions, such as a first micro-instruction for the multiplicative inverse function and a second micro-instruction for a modulo reduction such as one of 1801-1804. In processing block 2022, a source data operand set of elements is accessed. In processing block 2032, an irreducible polynomial is optionally explicitly identified. In one embodiment, the irreducible polynomial may be, for example,be specified in an immediate operand of the instruction as a hexadecimal control value 1B to calculate the polynomial x. 8 + x 4 + x 3 + x + 1 in the Galois field GF(256). In a further embodiment, the irreducible polynomial may be specified, for example, in an immediate operand of the instruction as a hexadecimal control value FA to represent the polynomial x 8 + x 7 + x 6 + x 5 + x 4 + x 2+ 1 in GF(256) or, alternatively, another polynomial. In another alternative embodiment, the polynomial may be specified and / or explicitly identified in the instruction mnemonic. In processing block 2042, a multiplicative inverse function of the binary finite field is computed for each element of the source data operand set, and in processing block 2052, the inverse for each element of the source data operand set is optionally reduced modulo the irreducible polynomial. In processing block 2082, a determination is made as to whether or not the processing of each element of the source data operand set has been completed. If not, the processing of the multiplicative inverse function of the SIMD finite field performs one more iteration, beginning in processing block 2042. Otherwise, in processing block 2092, a result of the affine SIMD transformation is stored in a SIMD destination register.

[0156] Fig. 20C illustrates a flow diagram for one embodiment of a process 2003 for executing an affine inverse function instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. In processing block 2013, an affine inverse function processor instruction is decoded for affine SIMD transform and inverse in a finite field. In processing block 2016, the affine inverse function instruction optionally generates micro-instructions, e.g., a first affine Fig.of the finite field and a second micro-instruction for a multiplicative inverse function 1604 of the finite field; or alternatively, a first micro-instruction for a matrix-vector multiplication 1601 of the finite field, followed by a second micro-instruction for a byte broadcast, a third micro-instruction for a vector addition (XOR) 1602 of the finite field, and a fourth micro-instruction for a multiplicative inverse function 1604 of the finite field. In processing block 2023, a source data operand set of elements is accessed. In processing block 2033, a transformation matrix operand is accessed. In processing block 2043, a translation vector operand is accessed. In processing block 2053, the transformation matrix operand is applied to each element of the source data operand set. In processing block 2063, the translation vector operand is applied to each transformed element of the source data operand set.In processing block 2073, a multiplicative inverse function of the binary finite field is computed for each affinely transformed element of the source data operand set. In processing block 2083, a determination is made as to whether or not the processing of each element of the source data operand set has been completed. If not, the processing of the affine SIMD transformation and inverse function executes a new iteration, beginning in processing block 2053. Otherwise, in processing block 2093, a result of the affine SIMD transformation and multiplicative inverse function is stored in a SIMD destination register.

[0157] Fig.20D illustrates a flow diagram for one embodiment of a process 2004 for executing a binary finite field multiplication instruction to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality. In processing block 2014, a multiplication processor instruction for SIMD multiplication in a finite field is decoded. In processing block 2016, decoding the affine inverse function instruction optionally generates micro-instructions, such as a first micro-instruction for carry-free multiplication 1913 and a second micro-instruction for finite field modulo reduction 1917, such as one of 1801-1804. In processing block 2024, a first source data operand set of elements is accessed. In processing block 2034, a second source data operand set of elements is accessed. In processing block 2044, an irreducible polynomial is optionally explicitly identified.In one embodiment, the irreducible polynomial may be specified, for example, in an immediate operand of the instruction as a hexadecimal control value 1B to represent the polynomial x. 8 + x 4 + x 3 + x + 1 in the Galois field GF(256). In a further embodiment, the irreducible polynomial may be specified, for example, in an immediate operand of the instruction as a hexadecimal control value FA to represent the polynomial x 8 + x 7 + x 6 + x 5 + x 4 + x 2+ 1 in GF(256). In another alternative embodiment, the polynomial may be specified and / or explicitly identified in the instruction mnemonic. In processing block 2054, a product of a pair of corresponding elements is computed for each of the corresponding elements of the first and second source data operand sets, and in processing block 2064, the product is optionally reduced modulo the irreducible polynomial for each of the corresponding elements of the first and second source data operand sets. In processing block 2084, a determination is made as to whether or not the processing of each of the corresponding elements from the first and second source data operand sets has been completed. If not, the finite field SIMD multiplication processing performs another iteration, beginning in processing block 2054.Otherwise, in processing block 2094, a result of the SIMD multiplication of the finite field is stored in a SIMD destination register.

[0158] It should be noted that, although the processes for executing instructions to provide general-purpose SIMD cryptographic arithmetic functionality have been illustrated above as iterative, one or more instantiations of the various processing blocks may be executed concurrently and / or in parallel, and are preferably executed whenever possible to increase execution performance and throughput.

[0159] It is noted that general-purpose GF(256) SIMD cryptographic arithmetic instructions can be used to provide general-purpose GF(256) SIMD cryptographic arithmetic functionality in applications such as cryptographic protocols and Internet communications to ensure data integrity, identity verification, message content authentication, and message origin authentication for financial transactions, electronic shopping, electronic mail, software distribution, data storage, etc. Therefore, it is further noted that providing for the execution of instructions at least for: (1) an affine SIMD transformation specifying a source data operand, a transformation matrix operand, and a translation vector, where the transformation matrix is applied to each element of the source data operand and the translation vector is applied to each of the transformed elements;(2) a multiplicative SIMD inverse function for a binary finite field to compute an inverse function in a binary finite field modulo an irreducible polynomial for each element of the source data operand; (3) an affine SIMD transform and multiplicative inverse function (or multiplicative inverse function and affine transform) specifying a source data operand, a transformation matrix operand, and a translation vector, where either before or after the multiplicative inverse operation, the transformation matrix is applied to each element of the source data operand and the translation vector is applied to each of the transformed elements; (4) a modulo reduction to perform the reduction modulo a particular modulo polynomial p; sto calculate a finite field selected from polynomials in a binary finite field for modulo reduction provided by the instruction (or micro-instruction); (5) a binary field SIMD multiplication specifying first and second source data operands, each of which corresponds to a pair of elements of the first and second source data operands modulo an irreducible polynomial; wherein the results of the instruction are stored in SIMD destination registers; may provide general-purpose GF(256) and / or other alternative finite binary field SIMD cryptographic arithmetic functionality in hardware and / or microcode sequences to support significant performance improvements for several important performance-critical applications without excessive or unreasonable functional units requiring additional circuitry, area, or power.Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementation approaches. Embodiments of the invention may be implemented as computer programs or program code executing on programmable systems comprising at least one processor, a memory system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0160] Program code can 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 that includes a processor, such as a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0161] The program code can be implemented in a high-level procedural or object-oriented programming language to communicate with a processing system. The program code can also be implemented in assembly or machine language, if desired. Indeed, the mechanisms described here are not limited to any programming language within the scope of protection. In any case, the language can be a compiled or translated language.

[0162] One or more aspects of the present embodiment may be implemented by representative instructions stored on a machine-readable medium representing various logic within the processor, which, when read by a machine, cause the machine to manufacture logic to perform the techniques described herein. Such representations, known as "IP cores," may be stored on a tangible machine-readable medium and delivered to various customers or manufacturing plants for loading into the manufacturing machines that actually manufacture the logic or processor.

[0163] Such machine-readable storage media may include, without limitation, non-transitory, tangible assemblies of objects manufactured or formed by a machine or device containing storage media such as hard disks, any other type of disk including floppy disks, optical disks, compact disk read-only memories (CD-ROMs), rewritable compact disks (CD-RWs), and magneto-optical disks, semiconductor devices such as read-only memories (ROMs), random access memories (RAMs), dynamic random access memories (DRAMs), static random access memories (SRAMs), erasable programmable read-only memories (EPROMs), flash memory, electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, and any other type of media suitable for storing electronic instructions.

[0164] Accordingly, embodiments of the invention also include non-transitory, tangible machine-readable media containing instructions or design data, such as hardware description language (HDL), that define structures, circuits, devices, processors, and / or system features described herein. Some embodiments may also be referred to as program products.

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

Claims

[1] Processor comprising: a decode stage (440) for decoding a first instruction for a multiplicative one-instruction-multiple-data inverse function, SIMD inverse function, for a binary finite field, the first instruction specifying a source data operand set and a normalized irreducible polynomial; and one or more execution units (460) responsive to the decoded first instruction to: to calculate a multiplicative SIMD inverse function for a binary finite field modulo the irreducible polynomial for each element of the source data operand set; and to store a result of the first instruction in a SIMD destination register (458). [2] The processor of claim 1, wherein the first instruction specifies the SIMD destination register (458) as a destination operand. [3] The processor of claim 1 or 2, wherein the first instruction specifies a SIMD register to hold 16-byte elements, 32-byte elements, or 64-byte elements as the source data operand set. [4] A processor according to any one of the preceding claims, wherein calculating the multiplicative SIMD inverse function of the binary finite field is performed by raising each element of the source data operand set to the power 254 modulo the irreducible polynomial in the Galois field GF(2 8 ) is executed. [5] A processor according to claim 1, wherein the irreducible polynomial is specified in the first instruction mnemonic as 1B to x 8 + x 4 + x 3 + x + 1 in the Galois field GF(2 8 ) must be specified. [6] A processor according to any one of claims 1 to 4, wherein the irreducible polynomial is specified in an immediate operand of the first instruction as a hexadecimal control value 1B to x 8 + x4 + x 3 + x + 1 in the Galois field GF(2 8 ) must be specified. [7] A processor according to any one of claims 1 to 4, wherein the irreducible polynomial is specified in an immediate operand of the first instruction as a hexadecimal control value F5 to x 8 + x 7 + x 6 + x 5 + x 4 + x 2 + 1 in the Galois field GF(2 8 ) must be specified. [8] Machine-readable medium for recording functionally descriptive material containing one or more executable instructions which, when executed on behalf of a thread of a machine, cause the machine to: accesses a source data operand set of elements and a normalized irreducible polynomial; computes a multiplicative one-instruction-multiple-data, SIMD, inverse function of a binary finite field modulo the irreducible polynomial for each element of the source data operand set; and stores a result of the multiplicative SIMD inverse function of the binary finite field modulo the irreducible polynomial in a SIMD destination register (458). [9] The machine-readable medium of claim 8, wherein the irreducible polynomial is specified in an immediate operand of a first instruction as a hexadecimal control value 1B to x 8 + x 4 + x 3 + x + 1 in the Galois field GF(2 8 ) must be specified. [10] The machine-readable medium of claim 8, wherein the irreducible polynomial is specified in a first instruction mnemonic as 1B to x 8 + x 4 + x 3 + x + 1 in the Galois field GF(2 8 ) must be specified. [11] Procedure comprising: Decoding a first instruction for a multiplicative one-instruction-multiple-data, SIMD, inverse function for a binary finite field, the first instruction specifying a source data operand set and a normalized irreducible polynomial; Computing a multiplicative SIMD inverse function of a binary finite field modulo the irreducible polynomial for each element of the source data operand set in response to the decoded first instruction; and Storing a result of the first instruction in a SIMD destination register (458). [12] The method of claim 11, wherein the normalized irreducible polynomial is specified in an immediate operand of the first instruction as a hexadecimal control value 1B to x 8 + x 4 + x 3 + x + 1 in the Galois field GF(2 8 ) must be specified. [13] The method of claim 11, wherein the irreducible polynomial is specified in the first instruction mnemonic as 1B to x 8 + x 4 + x 3 + x + 1 in the Galois field GF(2 8 ) must be specified. [14] Processing system comprising: a memory to store a first instruction for a round slice of a secure SIMD hash algorithm; and a processor comprising: a command fetch stage for fetching the first command; a decode stage (440) for decoding a first instruction for a multiplicative one-instruction-multiple-data, SIMD, inverse function of a binary finite field, the first instruction specifying a source data operand set and a normalized irreducible polynomial; and one or more execution units (460) responsive to the decoded first instruction to: to calculate a multiplicative SIMD inverse function of a binary finite field modulo the irreducible polynomial for each element of the source data operand set; and to store a result of the first instruction in a SIMD destination register (458). [15] The processing system of claim 14, wherein the irreducible polynomial is specified in the first instruction mnemonic as 1B to x 8 + x 4 + x 3 + x + 1 in the Galois field GF(2 8 ) must be specified. [16] The processing system of claim 14 or 15, wherein the first instruction is further for an affine SIMD transform of each multiplicative inverse function of the binary finite field, and the one or more execution units (460) are further for, in response to the decoded first instruction: Performing an affine SIMD transformation by applying a transformation matrix operand to the multiplicative inverse of each element of the source data operand set and applying a translation vector operand to each transformed multiplicative inverse of an element of the source data operand set to produce a result of the first instruction. [17] A processing system according to any one of claims 14 to 16, wherein the irreducible polynomial is specified in an immediate operand of the first instruction as a hexadecimal control value 1B to x 8 + x 4 + x 3 + x + 1 in the Galois field GF(2 8 ) must be specified. [18] A processing system according to any one of claims 14 to 16, wherein the irreducible polynomial is specified in an immediate operand of the first instruction as a hexadecimal control value 87 to x 128 + x 7 + x 2 + x + 1 in the Galois field GF(2 128 ) must be specified. [19] A processing system according to any one of claims 14 to 16, wherein the irreducible polynomial is specified in an immediate operand of the first instruction as a hexadecimal control value F5 to x 8 + x 7 + x 6 + x 5 + x 4 + x 2 + 1 in the Galois field GF(2 8 ) must be specified. [20] Apparatus for performing a multiplicative single-instruction-multiple-data, SIMD, inverse operation of a binary finite field, the apparatus comprising: means for accessing a source data operand set of elements and a normalized irreducible polynomial; Means for computing a multiplicative SIMD inverse function of a binary finite field modulo the irreducible polynomial for each element of the source data operand set; and Means for storing a result of the multiplicative SIMD inverse function of the binary finite field modulo the irreducible polynomial in a SIMD destination register (458). [21] The apparatus of claim 20, wherein the normalized irreducible polynomial is specified in an immediate operand of a first instruction as a hexadecimal control value 1B to x 8 + x 4 + x 3 + x + 1 in the Galois field GF(2 8 ) must be specified. [22] The apparatus of claim 20, wherein the normalized irreducible polynomial is specified in a first instruction mnemonic as 1B to x 8 + x 4 + x 3 + x + 1 in the Galois field GF(2 8 ) must be specified. [23] The apparatus of claim 20, wherein the normalized irreducible polynomial is specified in an immediate operand of a first instruction as a hexadecimal control value F5 to x 8 + x 7 + x 6 + x 5 + x4 + x 2 + 1 in the Galois field GF(2 8 ) must be specified.

Images