Patent Publication Number: US-7725521-B2

Title: Method and apparatus for computing matrix transformations

Description:
RELATED APPLICATIONS 
   This is continuation-in-part application claiming, under 35 U.S.C. §120, the benefit of the filing date of U.S. application Ser. No. 09/952,891, filed Oct. 29, 2001, now U.S. Pat. No. 7,085,795. 

   FIELD OF THE DISCLOSURE 
   This disclosure relates generally to transformation coding techniques for compression and decompression of audio, images and video. In particular, the disclosure relates to performing matrix transformations using Single-Instruction-Multiple-Data (SIMD) operations. 
   BACKGROUND OF THE DISCLOSURE 
   Media applications have been driving microprocessor development for more than a decade. In fact, most computing upgrades in recent years have been driven by media applications. These upgrades have predominantly occurred within consumer segments, although significant advances have also been seen in enterprise segments for entertainment enhanced education and communication purposes. Nevertheless, future media applications will require even higher computational requirements. As a result, tomorrow&#39;s personal computing (PC) experience will be even richer in audio-visual effects, as well as being easier to use, and more importantly, computing will merge with communications. 
   Accordingly, the display of images, as well as playback of audio and video data, which is collectively referred to herein as content, have become increasingly popular applications for current computing devices. Transformation coding is a popular technique for compression and decompression of audio, images and video. Discrete transformations such as the discrete cosine transform (DCT) used in prior compression techniques have made use of floating-point or fixed-point number representations to approximate real irrational coefficients. However imperfections in these representations may contribute to an inverse transformation mismatch when performed in the integer domain. 
   More recently matrix transformations have been proposed, which have integer basis components and permit coefficients to be accurately represented by integers. By choosing coefficients which are integer approximations of DCT coefficients, the near optimum decorrelation properties of DCTs are preserved. More over, small integer coefficients may be selected to permit transforms to be implemented with shifts, additions and subtractions rather than multiplications, and some adverse effects of rounding may be avoided. 
   In some computer systems, processors are implemented to operate on values represented by a large number of bits (e.g., 32 or 64) using instructions that produce one result. For example, the execution of an add instruction will add together a first 64-bit value and a second 64-bit value and store the result as a third 64-bit value. However, media applications require the manipulation of large amounts of data which may be represented in a small number of bits. For example, image data typically requires 8 or 16 bits and sound data typically requires 8 or 16 bits. To improve efficiency of media applications, some prior art processors provide packed data formats. A packed data format is one in which the bits typically used to represent a single value are broken into a number of fixed sized data elements, each of which represents a separate value. For example, a 64-bit register may be broken into two 32-bit elements, each of which represents a separate 32-bit value. In addition, these prior art processors provide instructions for separately manipulating each element in these packed data types in parallel. For example, a packed add instruction adds together corresponding data elements from a first packed data and a second packed data. Thus, if a multimedia algorithm requires a loop containing five operations that must be performed on a large number of data elements, it is desirable to pack the data and perform these operations in parallel using packed data instructions. In this manner, these processors can more efficiently process content of media applications. 
   Unfortunately, current methods and instructions target the general needs of transformations and are not comprehensive. In fact, many architectures do not support a means for efficiently performing matrix transformation calculations over a range of coefficient sizes and data types. In addition, data ordering within data storage devices such as SIMD registers, are generally not supported. As a result, current architectures require unnecessary data type changes which minimizes the number of operations per instruction and significantly increases the number of clock cycles required to order data for arithmetic operations. 
   Therefore, there remains a need to overcome one or more of the limitations existing in the techniques above-described. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     The present invention is illustrated by way of example and not limitation in the figures of the accompanying drawings. 
       FIGS. 1   a - 1   c  illustrate exemplary computer systems according to various alternative embodiments of the invention. 
       FIGS. 2   a - 2   b  illustrate register files of processors according to various alternative embodiments of the invention. 
       FIG. 3  illustrates a flow diagram for one embodiment of a process used by the processor to manipulate data. 
       FIGS. 4   a - 4   b  illustrate packed data-types according to various alternative embodiments of the invention. 
       FIGS. 5   a - 5   d  illustrate in-register packed data representations according to various alternative embodiments of the invention. 
       FIGS. 6   a - 6   d  illustrate operation encoding (opcode) formats for indicating the use of packed data according to various alternative embodiments of the invention. 
       FIGS. 7   a - 7   b  illustrate flow diagrams for various alternative embodiments of processes for performing multiply-add and multiply-subtract operations on packed byte data. 
       FIGS. 8   a - 8   d  illustrate alternative embodiments of circuits for performing multiply-add and multiply-subtract operations on packed data. 
       FIGS. 9   a - 9   b  illustrate flow diagrams of prior art processes for performing unpack operations on packed data. 
       FIGS. 10   a - 10   c  illustrate flow diagrams for various alternative embodiments of processes for performing shuffle operations on packed data. 
       FIGS. 11   a - 11   b  illustrate alternative embodiments of circuits for performing shuffle operations on packed data. 
       FIG. 12  illustrates one exemplary embodiment of a matrix transformation for processing of content data. 
       FIGS. 13   a - 13   b  illustrate flow diagrams for alternative embodiments of processes for performing matrix transformations. 
       FIGS. 14   a - 14   b  illustrate a flow diagram for one embodiment of a process for shuffling content data in matrix transformations. 
       FIG. 15  illustrates a flow diagram for an alternative embodiment of a process for shuffling content data in matrix transformations. 
       FIGS. 16   a - 16   b  illustrate a flow diagram for one embodiment of a process for using multiply-add to generate a matrix product in matrix transformations. 
       FIG. 17  illustrates a flow diagram for another embodiment of a process for using multiply-add to generate a matrix product in matrix transformations. 
   

   DETAILED DESCRIPTION 
   A method and apparatus for performing matrix transformations of content data are described. The method and apparatus includes instructions for multiply-add operations and byte shuffle operations on packed data in a processor. In one embodiment, two rows of content data elements are shuffled to generate a first and second packed data respectively including elements of a first two columns and of a second two columns. A third packed data including sums of products is generated from the first packed data and elements from two rows of a matrix by a multiply-add instruction. A fourth packed data including sums of products is generated from the second packed data and elements from two more rows of the matrix by another multiply-add instruction. Corresponding sums of products of the third and fourth packed data are then summed to generate two rows of a product matrix. 
   Elements of the product matrix may be generated in an order that further facilitates a second matrix multiplication. In one embodiment a fifth packed data including sums of products is generated from the first two rows of the product matrix and two columns of a row of a second matrix by a multiply-add instruction. A sixth packed data including sums of products is generated from the next two rows of the product matrix and two other columns of the row of a second matrix by another multiply-add instruction. Corresponding sums of products of the fifth and sixth packed data are then summed to generate a row of the second product matrix. 
   Further disclosed herein is a method and apparatus for including in a processor, instructions for performing multiply-add operations on pairs of adjacent packed data and for performing shuffle operations to reorder packed data. In one embodiment, a processor is coupled to a memory that stores a first packed byte data and a second packed byte data. The processor performs operations on said first packed byte data and said second packed byte data to generate a third packed data in response to receiving a multiply-add instruction. A plurality of the 16-bit data elements in this third packed data store the result of performing multiply-add operations on data elements in the first and second packed byte data. The order of byte elements in said first packed data may be adjusted in one of numerous ways to facilitate multiply-add operations by the processor performing data movement operations in response to receiving a shuffle instruction. 
   In one embodiment, methods of the present invention are embodied in machine-executable instructions. The instructions can be used to cause a general-purpose or special-purpose processor that is programmed with the instructions to perform the steps of the method. Alternatively, the steps of the method might be performed by specific hardware components that contain hardwired logic for performing the steps, or by any combination of programmed computer components and custom hardware components. 
   The present invention may be provided as a computer program product which may include a machine or computer-readable medium having stored thereon instructions which may be used to program a computer (or other electronic devices) to perform a process according to the present invention. The computer-readable medium may include, but is not limited to, floppy diskettes, optical disks, Compact Disc, Read-Only Memory (CD-ROMs), and magneto-optical disks, Read-Only Memory (ROMs), Random Access Memory (RAMs), Erasable Programmable Read-Only Memory (EPROMs), Electrically Erasable Programmable Read-Only Memory (EEPROMs), magnetic or optical cards, flash memory, or the like. 
   Accordingly, the computer-readable medium includes any type of media/machine-readable medium suitable for storing electronic instructions. Moreover, the present invention may also be downloaded as a computer program product. As such, the program may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client). The transfer of the program may be by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem, network connection or the like). 
   In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details. In addition, the following description provides examples, and the accompanying drawings show various examples for the purposes of illustration. In some instances, well-known structures and devices may be omitted in order to avoid obscuring the details of the present invention. These examples and other embodiments of the present invention may be realized in accordance with the following teachings and it should be evident that various modifications and changes may be made in the following teachings without departing from the broader spirit and scope of the invention. The specification and drawings are, accordingly, to be regarded in an illustrative rather than restrictive sense and the invention measured only in terms of the claims. 
   Computer System 
     FIG. 1   a  illustrates an exemplary computer system  100  according to one embodiment of the invention. Computer system  100  includes a bus  101 , or other communications hardware and software, for communicating information, and a processor  109  coupled with bus  101  for processing information. Processor  109  represents a central processing unit of any type of architecture, including a CISC or RISC type architecture. Computer system  100  further includes a random access memory (RAM) or other dynamic storage device (referred to as main memory  104 ), coupled to bus  101  for storing information and instructions to be executed by processor  109 . Main memory  104  also may be used for storing temporary variables or other intermediate information during execution of instructions by processor  109 . Computer system  100  also includes a read only memory (ROM)  106 , and/or other static storage device, coupled to bus  101  for storing static information and instructions for processor  109 . Data storage device  107  is coupled to bus  101  for storing information and instructions. 
     FIG. 1   a  also illustrates that processor  109  includes an execution unit  130 , a register file  150 , a cache  160 , a decoder  165 , and an internal bus  170 . Of course, processor  109  contains additional circuitry which is not necessary to understanding the invention. 
   Execution unit  130  is used for executing instructions received by processor  109 . In addition to recognizing instructions typically implemented in general purpose processors, execution unit  130  recognizes instructions in packed instruction set  140  for performing operations on packed data formats. Packed instruction set  140  includes instructions for supporting multiply-add and/or multiply-subtract operations. In addition, packed instruction set  140  may also include instructions for supporting a pack and an unpack operation, a packed shift operation, packed arithmetic operations (including a packed add operation, a packed subtract operation, a packed multiply operation, a packed a packed compare operation) and a set of packed logical operations (including packed AND, packed ANDNOT, packed OR, and packed XOR) as described in “A Set of Instructions for Operating on Packed Data,” filed on Aug. 31, 1995, application Ser. No. 08/521,360. Packed instruction set  140  may also include one or more instructions for supporting: a move data operation; a data shuffle operation for organizing data within a data storage device; an adjacent-add instruction for adding adjacent bytes, words and doublewords, two word values, two words to produce a 16-bit result, two quadwords to produce a quadword result; and a register merger operation as are described in “An Apparatus and Method for Efficient Filtering and Convolution of Content Data,” filed on Oct. 29, 2001, application Ser. No. 09/952,891. 
   Execution unit  130  is coupled to register file  150  by internal bus  170 . Register file(s)  150  represents a storage area on processor  109  for storing information, including data. It is understood that one aspect of the invention is the described instruction set for operating on packed data. According to this aspect of the invention, the storage area used for storing the packed data is not critical. However, embodiments of the register file  150  are later described with reference to  FIGS. 2   a - 2   b . Execution unit  130  is coupled to cache  160  and decoder  165 . Cache  160  is used to cache data and/or control signals from, for example, main memory  104 . Decoder  165  is used for decoding instructions received by processor  109  into control signals and/or microcode entry points. In response to these control signals and/or microcode entry points, execution unit  130  performs the appropriate operations. For example, if an add instruction is received, decoder  165  causes execution unit  130  to perform the required addition; if a subtract instruction is received, decoder  165  causes execution unit  130  to perform the required subtraction; etc. Decoder  165  may be implemented using any number of different mechanisms (e.g., a look-up table, a hardware implementation, a PLA, etc.). Thus, while the execution of the various instructions by the decoder and execution unit is represented by a series of if/then statements, it is understood that the execution of an instruction does not require a serial processing of these if/then statements. Rather, any mechanism for logically performing this if/then processing is considered to be within the scope of the invention. 
     FIG. 1   a  additionally shows a data storage device  107  (e.g., a magnetic disk, optical disk, and/or other machine readable media) can be coupled to computer system  100 . In addition, the data storage device  107  is shown including code  195  for execution by the processor  109 . The code  195  can be written to cause the processor  109  to perform transformations, bilinear interpolation, filters or convolutions with the multiply-add/subtract instruction(s) for any number of purposes (e.g., motion video compression/decompression, image filtering, audio signal compression, filtering or synthesis, modulation/demodulation, etc.). Computer system  100  can also be coupled via bus  101  to a display device  121  for displaying information to a computer user. Display device  121  can include a frame buffer, specialized graphics rendering devices, a cathode ray tube (CRT), and/or a flat panel display. An alphanumeric input device  122 , including alphanumeric and other keys, is typically coupled to bus  101  for communicating information and command selections to processor  109 . Another type of user input device is cursor control  123 , such as a mouse, a trackball, a pen, a touch screen, or cursor direction keys for communicating direction information and command selections to processor  109 , and for controlling cursor movement on display device  121 . This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), which allows the device to specify positions in a plane. However, this invention should not be limited to input devices with only two degrees of freedom. 
   Another device which may be coupled to bus  101  is a hard copy device  124  which may be used for printing instructions, data, or other information on a medium such as paper, film, or similar types of media. Additionally, computer system  100  can be coupled to a device for sound recording, and/or playback  125 , such as an audio digitizer coupled to a microphone for recording information. Further, the device may include a speaker which is coupled to a digital to analog (D/A) converter for playing back the digitized sounds. 
   Also, computer system  100  can be a terminal in a computer network (e.g., a LAN). Computer system  100  would then be a computer subsystem of a computer network. Computer system  100  optionally includes video digitizing device  126  and/or a communications device  190  (e.g., a serial communications chip, a wireless interface, an ethernet chip or a modem, which provides communications with an external device or network). Video digitizing device  126  can be used to capture video images that can be transmitted to others on the computer network. 
   In one embodiment, the processor  109  additionally supports an instruction set which is compatible with the x86 instruction set used by existing processors (such as the Pentium® processor) manufactured by Intel Corporation of Santa Clara, Calif. Thus, in one embodiment, processor  109  supports all the operations supported in the IA™—Intel Architecture, as defined by Intel Corporation of Santa Clara, Calif. (see “IA-32 Intel® Architecture Software Developers Manual Volume 2: Instruction Set Reference,” Order Number 245471, available from Intel of Santa Clara, Calif. on the world wide web at developer.intel.com). As a result, processor  109  can support existing x86 operations in addition to the operations of the invention. Processor  109  may also be suitable for manufacture in one or more process technologies and by being represented on a machine readable media in sufficient detail, may be suitable to facilitate said manufacture. While the invention is described as being incorporated into an x86 based instruction set, alternative embodiments could incorporate the invention into other instruction sets. For example, the invention could be incorporated into a 64-bit processor using a new instruction set. 
     FIG. 1   b  illustrates an alternative embodiment of a data processing system  102  which implements the principles of the present invention. One embodiment of data processing system  102  is an Intel® Personal Internet Client Architecture (Intel® PCA) applications processors with Intel XScale™ technology (as described on the world-wide web at developer.intel.com). It will be readily appreciated by one of skill in the art that the embodiments described herein can be used with alternative processing systems without departure from the scope of the invention. 
   Computer system  102  comprises a processing core  110  capable of performing SIMD operations including multiply-add and/subtract operations, pack and unpack operations, shuffle operations, packed shift operations, and packed arithmetic and logical operations. For one embodiment, processing core  110  represents a processing unit of any type of architecture, including but not limited to a CISC, a RISC or a VLIW type architecture. Processing core  110  may also be suitable for manufacture in one or more process technologies and by being represented on a machine readable media in sufficient detail, may be suitable to facilitate said manufacture. 
   Processing core  110  comprises an execution unit  130 , a set of register file(s)  150 , and a decoder  165 . Processing core  110  also includes additional circuitry (not shown) which is not necessary to the understanding of the present invention. 
   Execution unit  130  is used for executing instructions received by processing core  110 . In addition to recognizing typical processor instructions, execution unit  220  recognizes instructions in packed instruction set  140  for performing operations on packed data formats. Packed instruction set  140  includes instructions for supporting multiply-add/subtract operations and shuffle operations, and may also include other packed instructions. 
   Execution unit  130  is coupled to register file  150  by an internal bus. Register file  150  represents a storage area on processing core  110  for storing information, including data. As previously mentioned, it is understood that the storage area used for storing the packed data is not critical. Execution unit  130  is coupled to decoder  165 . Decoder  165  is used for decoding instructions received by processing core  110  into control signals and/or microcode entry points. In response to these control signals and/or microcode entry points, execution unit  130  performs the appropriate operations. 
   Processing core  110  is coupled with bus  214  for communicating with various other system devices, which may include but are not limited to, for example, synchronous dynamic random access memory (SDRAM) control  271 , static random access memory (SRAM) control  272 , burst flash memory interface  273 , personal computer memory card international association (PCMCIA)/compact flash (CF) card control  274 , liquid crystal display (LCD) control  275 , direct memory access (DMA) controller  276 ; and alternative bus master interface  277 . 
   In one embodiment, data processing system  102  may also comprise an I/O bridge  290  for communicating with various I/O devices via an I/O bus  295 . Such I/O devices may include but are not limited to, for example, universal asynchronous receiver/transmitter (UART)  291 , universal serial bus (USB)  292 , Bluetooth wireless UART  293  and I/O expansion interface  294 . 
   One embodiment of data processing system  102  provides for mobile, network and/or wireless communications and a processing core  110  capable of performing SIMD operations including multiply add/subtract operations and/or shuffle operations. Processing core  110  may be programmed with various audio, video, imaging and communications algorithms including transformations, filters or convolutions; compression/decompression techniques such as color space transformation, bilinear interpolation, video encode motion estimation or video decode motion compensation; and modulation/demodulation (MODEM) functions such as pulse coded modulation (PCM). 
     FIG. 1   c  illustrates alternative embodiments of a data processing system  103  capable of performing SIMD multiply-add/subtract operations and shuffle operations. In accordance with one alternative embodiment, data processing system  103  may include a main processor  224 , a SIMD coprocessor  226 , a cache memory  278  and an input/output system  265 . The input/output system  295  may optionally be coupled to a wireless interface  296 . SIMD coprocessor  226  is capable of performing SIMD operations including multiply-add/subtract operations, pack and unpack operations, shuffle operations, packed shift operations, and packed arithmetic and logical operations. Processing core  110  may be suitable for manufacture in one or more process technologies and by being represented on a machine readable media in sufficient detail, may be suitable to facilitate the manufacture of all or part of data processing system  103  including processing core  110 . 
   For one embodiment, SIMD coprocessor  226  comprises an execution unit  130  and register file(s)  209 . One embodiment of main processor  224  comprises a decoder  165  to recognize instructions of instruction set  140  including SIMD multiply-add/subtract instructions, pack and unpack instructions, shuffle instructions, packed shift instructions, and packed arithmetic and logical instructions for execution by execution unit  130 . For alternative embodiments, SIMD coprocessor  226  also comprises at least part of decoder  165   b  to decode instructions of instruction set  140 . Processing core  110  also includes additional circuitry (not shown) which is not necessary to the understanding of the present invention. 
   In operation, the main processor  224  executes a stream of data processing instructions that control data processing operations of a general type including interactions with the cache memory  278 , and the input/output system  295 . Embedded within the stream of data processing instructions are SIMD coprocessor instructions. The decoder  165  of main processor  224  recognizes these SIMD coprocessor instructions as being of a type that should be executed by an attached SIMD coprocessor  226 . Accordingly, the main processor  224  issues these SIMD coprocessor instructions (or control signals representing SIMD coprocessor instructions) on the coprocessor bus  236  where from they are received by any attached SIMD coprocessors. In this case, the SIMD coprocessor  226  will accept and execute any received SIMD coprocessor instructions intended for it. 
   Data may be received via wireless interface  296  for processing by the SIMD coprocessor instructions. For one example, voice communication may be received in the form of a digital signal, which may be processed by the SIMD coprocessor instructions to regenerate digital audio samples representative of the voice communications. For another example, compressed audio and/or video may be received in the form of a digital bit stream, which may be processed by the SIMD coprocessor instructions to regenerate digital audio samples and/or motion video frames. 
   For one embodiment of processing core  110 , main processor  224  and a SIMD coprocessor  226  are integrated into a single processing core  110  comprising an execution unit  130 , register file(s)  209 , and a decoder  165  to recognize instructions of instruction set  140  including SIMD multiply-add/subtract instructions, pack and unpack instructions, shuffle instructions, packed shift instructions, and packed arithmetic and logical instructions for execution by execution unit  130 . 
     FIG. 2   a  illustrates the register file of the processor according to one embodiment of the invention. The register file  150  may be used for storing information, including control/status information, integer data, floating point data, and packed data. In the embodiment shown in  FIG. 2   a , the register file  150  includes integer registers  201 , registers  209 , status registers  208 , and instruction pointer register  211 . Status registers  208  indicate the status of processor  109 . Instruction pointer register  211  stores the address of the next instruction to be executed. Integer registers  201 , registers  209 , status registers  208 , and instruction pointer register  211  are all coupled to internal bus  170 . Additional registers may also be coupled to internal bus  170 . 
   In one embodiment, the registers  209  are used for both packed data and floating point data. In one such embodiment, the processor  109 , at any given time, must treat the registers  209  as being either stack referenced floating point registers or non-stack referenced packed data registers. In this embodiment, a mechanism is included to allow the processor  109  to switch between operating on registers  209  as stack referenced floating point registers and non-stack referenced packed data registers. In another such embodiment, the processor  109  may simultaneously operate on registers  209  as non-stack referenced floating point and packed data registers. As another example, in another embodiment, these same registers may be used for storing integer data. 
   Of course, alternative embodiments may be implemented to contain more or less sets of registers. For example, an alternative embodiment may include a separate set of floating point registers for storing floating point data. As another example, an alternative embodiment may including a first set of registers, each for storing control/status information, and a second set of registers, each capable of storing integer, floating point, and packed data. As a matter of clarity, the registers of an embodiment should not be limited in meaning to a particular type of circuit. Rather, a register of an embodiment need only be capable of storing and providing data, and performing the functions described herein. 
   The various sets of registers (e.g., the integer registers  201 , the registers  209 ) may be implemented to include different numbers of registers and/or to different size registers. For example, in one embodiment, the integer registers  201  are implemented to store thirty-two bits, while the registers  209  are implemented to store eighty bits (all eighty bits are used for storing floating point data, while only sixty-four are used for packed data). In addition, registers  209  contains eight registers, R 0    212   a  through R 7    212   h . R 1    212   a , R 2    212   b  and R 3    212   c  are examples of individual registers in registers  209 . Thirty-two bits of a register in registers  209  can be moved into an integer register in integer registers  201 . Similarly, a value in an integer register can be moved into thirty-two bits of a register in registers  209 . In another embodiment, the integer registers  201  each contain 64 bits, and 64 bits of data may be moved between the integer register  201  and the registers  209 . In another alternative embodiment, the registers  209  each contain 64 bits and registers  209  contains sixteen registers. In yet another alternative embodiment, registers  209  contains thirty-two registers. 
     FIG. 2   b  illustrates the register file of the processor according to one alternative embodiment of the invention. The register file  150  may be used for storing information, including control/status information, integer data, floating point data, and packed data. In the embodiment shown in  FIG. 2   b , the register file  150  includes integer registers  201 , registers  209 , status registers  208 , extension registers  210 , and instruction pointer register  211 . Status registers  208 , instruction pointer register  211 , integer registers  201 , registers  209 , are all coupled to internal bus  170 . Additionally, extension registers  210  are also coupled to internal bus  170 . 
   In one embodiment, the extension registers  210  are used for both packed integer data and packed floating point data. In alternative embodiments, the extension registers  210  may be used for scalar data, packed Boolean data, packed integer data and/or packed floating point data. Of course, alternative embodiments may be implemented to contain more or less sets of registers, more or less registers in each set or more or less data in each register without departing from the broader scope of the invention. 
   In one embodiment, the integer registers  201  are implemented to store thirty-two bits, the registers  209  are implemented to store eighty bits (all eighty bits are used for storing floating point data, while only sixty-four are used for packed data) and the extension registers  210  are implemented to store 128 bits. In addition, extension registers  210  may contain eight registers, XR 0    213   a  through XR 7    213   h . XR 1    213   a , XR 2    213   b  and R 3    213   c  are examples of individual registers in registers  210 . In another embodiment, the integer registers  201  each contain 64 bits, the registers  210  each contain 64 bits and registers  210  contains sixteen registers. In one embodiment two registers of registers  210  may be operated upon as a pair. In yet another alternative embodiment, registers  210  contains thirty-two registers. 
     FIG. 3  illustrates a flow diagram for one embodiment of a process  300  to manipulate data according to one embodiment of the invention. That is,  FIG. 3  illustrates a process followed, for example, by processor  109  while performing an operation on packed data, performing an operation on unpacked data, or performing some other operation. Process  300  and other processes herein disclosed are performed by processing blocks that may comprise dedicated hardware or software or firmware operation codes executable by general purpose machines or by special purpose machines or by a combination of both. 
   In processing block  301 , the decoder  165  receives a control signal from either the cache  160  or bus  101 . Decoder  165  decodes the control signal to determine the operations to be performed. 
   In processing block  302 , Decoder  165  accesses the register file  150 , or a location in memory. Registers in the register file  150 , or memory locations in the memory, are accessed depending on the register address specified in the control signal. For example, for an operation on packed data, the control signal can include SRC1, SRC2 and DEST register addresses. SRC1 is the address of the first source register. SRC2 is the address of the second source register. In some cases, the SRC2 address is optional as not all operations require two source addresses. If the SRC2 address is not required for an operation, then only the SRC1 address is used. DEST is the address of the destination register where the result data is stored. In one embodiment, SRC1 or SRC2 is also used as DEST. SRC1, SRC2 and DEST are described more fully in relation to  FIGS. 6   a - 6   d . The data stored in the corresponding registers is referred to as Source1, Source2, and Result respectively. In one embodiment, each of these data may be sixty-four bits in length. In an alternative embodiment, these data may be sixty-four or one hundred twenty-eight bits in length. 
   In another embodiment of the invention, any one, or all, of SRC1, SRC2 and DEST, can define a memory location in the addressable memory space of processor  109  or processing core  110 . For example, SRC1 may identify a memory location in main memory  104 , while SRC2 identifies a first register in integer registers  201  and DEST identifies a second register in registers  209 . For simplicity of the description herein, the invention will be described in relation to accessing the register file  150 . However, these accesses could be made to memory instead. 
   In processing block  303 , execution unit  130  is enabled to perform the operation on the accessed data. In processing block  304 , the result is stored back into register file  150  according to requirements of the control signal. 
   Data Storage Formats 
     FIG. 4   a  illustrates packed data-types according to one embodiment of the invention. Three packed data formats are illustrated; packed byte  411 , packed word  412 , and packed doubleword  413 . Packed byte, in one embodiment of the invention, is sixty-four bits long containing eight data elements. In an alternative embodiment, packed byte may be sixty-four or one hundred twenty-eight bits long containing eight or sixteen data elements. Each data element is one byte long. Generally, a data element is an individual piece of data that is stored in a single register (or memory location) with other data elements of the same length. In one embodiment of the invention, the number of data elements stored in a register is sixty-four bits or one hundred twenty-eight bits divided by the length in bits of a data element. 
   Packed word  412  may be sixty-four or one hundred twenty-eight bits long and contains four or eight word  412  data elements. Each word  412  data element contains sixteen bits of information. 
   Packed doubleword  413  may be sixty-four or one hundred twenty-eight bits long and contains two or four doubleword  413  data elements. Each doubleword  413  data element contains thirty-two bits of information. 
     FIG. 4   a  also illustrates a quadword  414  data-type according to one embodiment of the invention. Each quadword  414  data element contains sixty-four bits of information. 
     FIG. 4   b  illustrates packed data-types according to one alternative embodiment of the invention. Four packed data formats are illustrated; packed byte  421 , packed half  422 , packed single  423  and packed double  424 . Packed byte, in one embodiment of the invention, is one hundred twenty-eight bits long containing sixteen data elements. In an alternative embodiment, packed byte may be sixty-four or one hundred twenty-eight bits long containing eight or sixteen data elements. Each data element is one byte long. 
   Packed half  422  may be sixty-four or one hundred twenty-eight bits long and contains four or eight half  422  data elements. Each half  422  data element contains sixteen bits of information. 
   Packed single  423  may be sixty-four or one hundred twenty-eight bits long and contains two or four single  423  data elements. Each single  423  data element contains thirty-two bits of information. 
   Packed double  424  may be sixty-four or one hundred twenty-eight bits long and contains one or two double  424  data elements. Each double  424  data element contains sixty-four bits of information. 
   In one embodiment of the invention, packed single  423  and packed double  424  may be packed floating point data elements. In an alternative embodiment of the invention, packed single  423  and packed double  424  may be packed integer, packed Boolean or packed floating point data elements. In another alternative embodiment of the invention, packed byte  421 , packed half  422 , packed single  423  and packed double  424  may be packed integer or packed Boolean data elements. In alternative embodiments of the invention, not all of the packed byte  421 , packed half  422 , packed single  423  and packed double  424  data formats may be permitted. 
     FIGS. 5   a - 5   d  illustrate the in-register packed data storage representation according to one embodiment of the invention. Unsigned packed byte in-register representation  510  illustrates the storage of an unsigned packed byte, for example in one of the registers R 0    212   a  through R 7    212   h  or in half of one of the registers XR 0    213   a  through XR 7    213   h . Information for each byte data element is stored in bit seven through bit zero for byte zero, bit fifteen through bit eight for byte one, bit twenty-three through bit sixteen for byte two, bit thirty-one through bit twenty-four for byte three, bit thirty-nine through bit thirty-two for byte four, bit forty-seven through bit forty for byte five, bit fifty-five through bit forty-eight for byte six and bit sixty-three through bit fifty-six for byte seven. Thus, all available bits are used in the register. This storage arrangement increases the storage efficiency of the processor. As well, with eight data elements accessed, one operation can now be performed on eight data elements simultaneously. Signed packed byte in-register representation  511  illustrates the storage of a signed packed byte. Note that the eighth bit of every byte data element is the sign indicator. 
   Unsigned packed word in-register representation  512  illustrates how word three through word zero are stored in one register of registers  209  or in half of a register of registers  210 . Bit fifteen through bit zero contain the data element information for word zero, bit thirty-one through bit sixteen contain the information for data element word one, bit forty-seven through bit thirty-two contain the information for data element word two and bit sixty-three through bit forty-eight contain the information for data element word three. Signed packed word in-register representation  513  is similar to the unsigned packed word in-register representation  512 . Note that the sixteenth bit of each word data element is the sign indicator. 
   Unsigned packed doubleword in-register representation  514  shows how registers  209  or registers  210 , for example, store two doubleword data elements. Doubleword zero is stored in bit thirty-one through bit zero of the register. Doubleword one is stored in bit sixty-three through bit thirty-two of the register. Signed packed doubleword in-register representation  515  is similar to unsigned packed doubleword in-register representation  514 . Note that the necessary sign bit is the thirty-second bit of the doubleword data element. 
   Unsigned packed quadword in-register representation  516  shows how registers  210  store two quadword data elements. Quadword zero is stored in bit sixty-three through bit zero of the register. Quadword one is stored in bit one hundred twenty-seven through bit sixty-four of the register. Signed packed quadword in-register representation  517  is similar to unsigned packed quadword in-register representation  516 . Note that the necessary sign bit is the sixty-fourth bit of the quadword data element. 
   As mentioned previously, registers  209  may be used for both packed data and floating point data. In this embodiment of the invention, the individual programming processor  109  may be required to track whether an addressed register, R 0    212   a  for example, is storing packed data or floating point data. In an alternative embodiment, processor  109  could track the type of data stored in individual registers of registers  209 . This alternative embodiment could then generate errors if, for example, a packed addition operation were attempted on floating point data. 
   Operation Encoding Formats 
   Turning next to  FIG. 6   a , in some alternative embodiments, 64 bit single instruction multiple data (SIMD) arithmetic operations may be performed through a coprocessor data processing (CDP) instruction. Operation encoding (opcode) format  601  depicts one such CDP instruction having CDP opcode fields  611  and  618 . The type of CDP instruction, for alternative embodiments of multiply-add/subtract operations, pack and unpack operations, shuffle operations, packed shift operations, and packed arithmetic and logical operations may be encoded by one or more of fields  612 ,  613 ,  616  and  617 . Up to three operand locations per instruction may be identified, including up to two source operand identifiers SRC1  602  and SRC2  603  and one destination operand identifier DEST  605 . One embodiment of the coprocessor can operate on 8, 16, 32, and 64 bit values. For one embodiment, the multiply-addition/subtraction is performed on fixed-point or integer data values. For alternative embodiments, multiply-addition/subtraction may be performed on floating-point data values. In some embodiments, the multiply-add/subtract instructions, shuffle instructions and other SIMD instructions may be executed conditionally, using condition field  610 . For some multiply-add/subtract instructions and/or other SIMD instructions, source data sizes may be encoded by field  612 . 
   In some embodiments of the multiply-add/subtract instructions, Zero (Z), negative (N), carry (C), and overflow (V) detection can be done on SIMD fields. Also, signed saturation and/or unsigned saturation to the SIMD field width may be performed for some embodiments of multiply-add/subtract operations. In some embodiments of the multiply-add/subtract instructions in which saturation is enabled, saturation detection may also be done on SIMD fields. For some instructions, the type of saturation may be encoded by field  613 . For other instructions, the type of saturation may be fixed. 
     FIG. 6   b  is a depiction of an alternative operation encoding (opcode) format  621 , having twenty-four or more bits, and register/memory operand addressing modes corresponding with a type of opcode format described in the “IA-32 Intel Architecture Software Developer&#39;s Manual Volume 2: Instruction Set Reference,” (Order number 245471) which is available from Intel Corporation, Santa Clara, Calif. on the world-wide-web (www) at developer.intel.com. The type of operation, may be encoded by one or more of fields  622  and  624 . Up to two operand locations per instruction may be identified, including up to two source operand identifiers SRC1  602  and SRC2  603 . For one embodiment of the multiply-add/subtract instruction and the shuffle instruction, destination operand identifier DEST  605  is the same as source operand identifier SRC1  602 . For an alternative embodiment, destination operand identifier DEST  605  is the same as source operand identifier SRC2  603 . Therefore, for embodiments of the multiply-add/subtract operations and/or the shuffle operations, one of the source operands identified by source operand identifiers SRC1  602  and SRC2  603  is overwritten by the results of the multiply-add/subtract operations or the shuffle operations. For one embodiment of the multiply-add/subtract instruction and/or the shuffle instruction, operand identifiers SRC1  602  and SRC2  603  may be used to identify 64-bit source and destination operands. 
     FIG. 6   c  is a depiction of an alternative operation encoding (opcode) format  631 , having thirty-two or more bits, and register/memory operand addressing modes. The type of operation, may be encoded by one or more of fields  632  and  634  and up to two operand locations per instruction may be identified, including up to two source operand identifiers SRC1  602  and SRC2  603 . For example, in one embodiment of the multiply-add instruction, field  632  may be set to a hexadecimal value of 0F38 and field  634  may be set to a hexadecimal value of 04 to indicate that data associated with source operand identifier SRC1  602  is to be treated as unsigned packed bytes, data associated with source operand identifier SRC2  603  is to be treated as signed packed bytes and result data associated with destination operand identifier DEST  605  is to be treated as signed packed words. In one embodiment of the shuffle instruction, field  632  may be set to a hexadecimal value of 0F38 and field  634  may be set to a hexadecimal value of 00 to indicate that byte data is associated with source operand identifier SRC1  602  is to be reordered according to byte fields associated with source operand identifier SRC2  603  and stored as packed byte data associated with destination operand identifier DEST  605 . 
   For one embodiment, destination operand identifier DEST  605  is the same as source operand identifier SRC1  602 . For an alternative embodiment, destination operand identifier DEST  605  is the same as source operand identifier SRC2  603 . For one embodiment of the multiply-add/subtract instruction and/or the shuffle instruction, operand identifiers SRC1  602  and SRC2  603  of opcode format  631  may be used to identify 64-bit source and destination operands. For an alternative embodiment of the multiply-add/subtract instruction and/or the shuffle instruction, operand identifiers SRC1  602  and SRC2  603  may be used to identify 128-bit source and destination operands. 
   For one embodiment, opcode format  621 , opcode format  631  and other opcode formats described in the “IA-32 Intel Architecture Software Developer&#39;s Manual Volume 2: Instruction Set Reference,” (available from Intel Corporation, Santa Clara, Calif. on the world-wide-web at developer.intel.com) are each supported by decoder  165 . In alternative embodiments of decoder  165 , a plurality of instructions, each potentially having a different opcode format, may be decoded concurrently or in parallel. It will be appreciated that the decoding of opcode formats in a timely manner may be of critical importance to the performance of a processor such as processor  109 . One of the unique requirements of decoding multiple opcode formats of variable lengths is determining precisely where each instruction begins. In order to accomplish this requirement, the lengths of each of the plurality of opcode formats must be determined. 
   For example, in one embodiment of opcode format  621 , determining the length of an instruction requires examination of up to 27 bits from fields  622 ,  624 ,  626 ,  602 ,  603  and potentially from a 3-bit base field of an optional scale-index-base (SIB) byte (not shown), which is described in the “IA-32 Intel Architecture Software Developer&#39;s Manual Volume 2: Instruction Set Reference.” It will be appreciated that, if determining the length of an instruction using opcode format  631  requires examination of more bits than determining the length of an instruction using opcode format  621 , additional complexity and/or delays may be incurred. 
   For one embodiment of the multiply-add instruction and/or the shuffle instruction, field  632  may be set to a hexadecimal value of 0F38, which may be used in a manner substantially similar to that of fields  622  in determining the length of an instruction. Further, when field  632  is set to the hexadecimal value of 0F38, field  634  may be ignored by decoder  165  in determining the length of the instruction, thereby requiring examination of no more than 27 bits from fields  632 ,  626 ,  602 ,  603  and potentially from the 3-bit base field of an optional SIB byte. Thus opcode format  631  may be implemented in such a way as to provide additional flexibility and diversity of instruction encodings and avoid introduction of unnecessary complexity and/or delays in decoder  165 . 
     FIG. 6   d  is a depiction of another alternative operation encoding (opcode) format  641 , having forty or more bits. Opcode format  641  corresponds with opcode format  631  and comprises an optional prefix byte  640 . The type of multiply-add/subtract operation and/or shuffle operation, may be encoded by one or more of fields  640 ,  632  and  634 . Up to two operand locations per instruction may be identified by source operand identifiers SRC1  602  and SRC2  603  and by prefix byte  640 . For one embodiment of the multiply-add/subtract instruction and/or the shuffle instruction, prefix byte  640  may be used to identify 128-bit source and destination operands. For example, in one embodiment of the multiply-add instruction and/or the shuffle instruction, prefix byte  640  may be set to a hexadecimal value of 66, to indicate that 128 bits of data from one of the extension registers  210  are associated with source operand identifiers SRC1  602  and SRC2  603  and 128 bits of result data from one of the extension registers  210  are associated with destination operand identifier DEST  605 . 
   For one embodiment of the multiply-add/subtract instruction and/or the shuffle instruction, destination operand identifier DEST  605  is the same as source operand identifier SRC1  602 . For an alternative embodiment, destination operand identifier DEST  605  is the same as source operand identifier SRC2  603 . Therefore, for embodiments of the multiply-add/subtract operations and/or the shuffle operations, one of the source operands identified by source operand identifiers SRC1  602  and SRC2  603  of opcode format  631  or opcode format  641  is overwritten by the results of the multiply-add/subtract operations or of the shuffle operations. 
   Opcode formats  621 ,  631  and  641  allow register to register, memory to register, register by memory, register by register, register by immediate, register to memory addressing specified in part by MOD fields  626  and by optional scale-index-base and displacement bytes. 
   Description of Saturate/Unsaturate 
   As mentioned previously, in some embodiments multiply-add/subtract opcodes may indicate whether operations optionally saturate. In some alternative embodiments saturation may not be optional for a given multiply-add/subtract instruction. Where the result of an operation, with saturate enabled, overflows or underflows the range of the data, the result will be clamped. Clamping means setting the result to a maximum or minimum value should a result exceed the range&#39;s maximum or minimum value. In the case of underflow, saturation clamps the result to the lowest value in the range and in the case of overflow, to the highest value. The allowable ranges for data formats is shown in Table 5. 
   
     
       
         
             
             
             
             
           
             
                 
               TABLE 5 
             
             
                 
                 
             
             
                 
                 
               Minimum 
               Maximum 
             
             
                 
               Data Format 
               Value 
               Value 
             
             
                 
                 
             
           
          
             
                 
             
          
         
         
             
             
             
             
          
             
                 
               Unsigned Byte 
               0 
               255 
             
             
                 
               Signed Byte 
               −128 
               127 
             
             
                 
               Unsigned word 
               0 
               65535 
             
             
                 
               Signed word 
               −32768 
               32767 
             
             
                 
               Unsigned Doubleword 
               0 
               2 32  − 1 
             
             
                 
               Signed Doubleword 
                −2 31   
               2 31  − 1 
             
             
                 
               Unsigned Quadword 
               0 
               2 64  − 1 
             
             
                 
               Signed Quadword 
                −2 63   
               2 63  − 1 
             
             
                 
                 
             
          
         
       
     
   
   Therefore, using the unsigned byte data format, if an operation&#39;s result=258 and saturation was enabled, then the result would be clamped to 255 before being stored into the operation&#39;s destination register. Similarly, if an operation&#39;s result=−32999 and processor  109  used signed word data format with saturation enabled, then the result would be clamped to −32768 before being stored into the operation&#39;s destination register. 
   Multiply-Add/Subtract Operation(s) 
   In one embodiment of the invention, the SRC1 register contains packed data (Source1), the SRC2 register contains packed data (Source2), and the DEST register will contain the result (Result) of performing the multiply-add or multiply-subtract instruction on Source1 and Source2. In the first step of the multiply-add and multiply-subtract instruction, Source1 will have each data element independently multiplied by the respective data element of Source2 to generate a set of respective intermediate results. These intermediate results are summed by pairs to generate the Result for the multiply-add instruction. In contrast, these intermediate results are subtracted by pairs to generate the Result for the multiply-subtract instruction. 
   In some current processors, the multiply-add instructions operate on signed packed data and truncate the results to avoid any overflows. In addition, these instructions operate on packed word data and the Result is a packed double word. However, alternative embodiments of the multiply-add or the multiply-subtract instructions support other packed data types. For example, one embodiment may support the multiply-add or the multiply-subtract instructions on packed byte data wherein the Result is a packed word. 
     FIG. 7   a  illustrates a flow diagram for alternative embodiments of a process  711  for a performing multiply-add operation on packed byte data. Process  711  and other processes herein disclosed are performed by processing blocks that may comprise dedicated hardware or software or firmware operation codes executable by general purpose machines or by special purpose machines or by a combination of both. 
   In processing block  701 , decoder  165  decodes the control signal received by processor  109 . Thus, decoder  165  decodes the operation code for a multiply-add instruction. It will be appreciated that while examples are given of multiply-add, one of skill in the art could modify the teachings of this disclosure to also perform multiply-subtract without departing from the broader spirit of the invention as set forth in the accompanying claims. 
   In processing block  702 , via internal bus  170 , decoder  165  accesses registers  209  in register file  150  given the SRC1  602  and SRC2  603  addresses. Registers  209  provide execution unit  130  with the packed data stored in the SRC1  602  register (Source1), and the packed data stored in SRC2  603  register (Source2). That is, registers  209  (or extension registers  210 ) communicate the packed data to execution unit  130  via internal bus  170 . As noted above, Source1 data and Source2 data may be accessed from memory as well as from registers  209  (or extension registers  210 ) and the term “register” as used in these examples is not intended to limit the access to any particular kind of storage device. Rather, various embodiments, for example opcode formats  621 ,  631  and  641 , allow register to register, memory to register, register by memory, register by register, register by immediate, register to memory addressing. Therefore, a register of an embodiment need only be capable of storing and providing data, and performing the functions described herein. 
   In processing block  703 , decoder  165  enables execution unit  130  to perform the instruction. If the instruction is a multiply-add instruction for processing byte data, flow passes to processing block  718 . 
   In processing block  718 , the following is performed. Source1 bits seven through zero are multiplied by Source2 bits seven through zero generating a first 16-bit intermediate result (Intermediate Result 1). Source1 bits fifteen through eight are multiplied by Source2 bits fifteen through eight generating a second 16-bit intermediate result (Intermediate Result 2). Source1 bits twenty-three through sixteen are multiplied by Source2 bits twenty-three through sixteen generating a third 16-bit intermediate result (Intermediate Result 3). Source1 bits thirty-one through twenty-four are multiplied by Source2 bits thirty-one through twenty-four generating a fourth 16-bit intermediate result (Intermediate Result 4). Source1 bits thirty-nine through thirty-two are multiplied by Source2 bits thirty-nine through thirty-two generating a fifth 16-bit intermediate result (Intermediate Result 5). Source1 bits forty-seven through forty are multiplied by Source2 bits forty-seven through forty generating a sixth 16-bit intermediate result (Intermediate Result 6). Source1 bits fifty-five through forty-eight are multiplied by Source2 bits fifty-five through forty-eight generating a seventh 16-bit intermediate result (Intermediate Result 7). Source1 bits sixty-three through fifty-six are multiplied by Source2 bits sixty-three through fifty-six generating an eighth 16-bit intermediate result (Intermediate Result 8). Intermediate Result 1 is added to Intermediate Result 2 generating Result bits fifteen through zero, Intermediate Result 3 is added to Intermediate Result 4 generating Result bits thirty-one through sixteen, Intermediate Result 5 is added to Intermediate Result 6 generating Result bits forty-seven through thirty-two, and Intermediate Result 7 is added to Intermediate Result 8 generating Result bits sixty-three through forty-eight. 
   Processing of a multiply-subtract instruction on byte data is substantially the same as processing block  718 , with the exception that Intermediate Result 1 and Intermediate Result 2 are subtracted to generate Result bits fifteen through zero, Intermediate Result 3 and Intermediate Result 4 are subtracted to generate Result bits thirty-one through sixteen, Intermediate Result 5 and Intermediate Result 6 are subtracted to generate Result bits forty-seven through thirty-two, and Intermediate Result 7 and Intermediate Result 8 are subtracted to generate Result bits sixty-three through forty-eight. Different embodiments may perform the multiplies and adds/subtracts serially, in parallel, or in some combination of serial and parallel operations. 
   In processing block  720 , the Result is stored in the DEST register. 
   In one embodiment of processing block  718 , byte elements of Source1 are treated as unsigned values and byte elements of Source2 are treated as signed values during multiplication. In another embodiment of processing block  718 , Intermediate Results 1-8 are added/subtracted using signed saturation. It will be appreciated that alternative embodiments of process  711  may implement additional processing blocks to support additional variations of the multiply-add or multiply-subtract instructions. 
     FIG. 7   b  illustrates a flow diagram for an alternative embodiment of a process  721  for performing multiply-add operation on packed data. Processing blocks  701  through  703  are essentially the same as in process block  711 , with the exception that in processing block  703 , the instruction is a multiply-add instruction for performing byte multiplications on 128-bit packed data, and so flow passes to processing block  719 . 
   In processing block  719 , the multiplication operations are substantially the same as processing block  718 , with the exception that in similarity to Source1 bits seven through zero being multiplied by Source2 bits seven through zero to generate a first 16-bit intermediate result (Intermediate Result 1) and so forth through Source1 bits sixty-three through fifty-six being multiplied by Source2 bits sixty-three through fifty-six to generate an eighth 16-bit intermediate result (Intermediate Result 8), Source1 bits seventy-one through sixty-four are also multiplied by Source2 bits seventy-one through sixty-four to generate a ninth 16-bit intermediate result (Intermediate Result 9) and so forth through Source1 bits one hundred twenty-seven through one hundred and twenty which are multiplied by Source2 bits one hundred twenty-seven through one hundred and twenty to generate a sixteenth 16-bit intermediate result (Intermediate Result 16). Then Intermediate Results 1 and 2 are added generating Result bits fifteen through zero, and so forth with pairs of Intermediate Results 3 and 4, Intermediate Results 5 and 6, . . . through Intermediate Results 15 and 16 which are added together respectively generating Result bits thirty-one through sixteen, Result bits forty-seven through thirty-two, . . . through Result bits one hundred and twenty-seven through one hundred and twelve. 
   Again, in processing block  720 , the Result is stored in the DEST register. 
   It will be appreciated that alternative embodiments of processing blocks  718  or  719  may perform multiplication operations on signed or unsigned data elements or on a combination of both. It will also be appreciated that alternative embodiments of processing blocks  718  or  719  may perform addition and/or subtraction operations with or without saturation on signed or unsigned intermediate results or on a combination of both. 
   Packed Data Multiply-Add/Subtract Circuits 
   In one embodiment, the multiply-add and multiply-subtract instructions can execute on multiple data elements in the same number of clock cycles as a single multiply on unpacked data. To achieve execution in the same number of clock cycles, parallelism may be used. That is, registers may be simultaneously instructed to perform the multiply-add/subtract operations on the data elements. This is discussed in more detail below. 
     FIG. 8   a  illustrates a circuit for performing multiply-add and/or multiply-subtract operations on packed data according to one embodiment of the invention. FIG.  8   a  depicts a first source, Source1[63:0]  831 , and a second source, Source2[63:0]  833 . In one embodiment, the first and second sources are stored in N-bit long SIMD registers, such as for example 128-bit Intel® SSE2 XMM registers, or for example 64-bit MMX™ registers. For two pixel vectors  831  and  833 , the multiply-add instruction implemented on such registers would give the following results, Result[63:0]  890 , which are stored to the destination. Accordingly, the example shows an 8-bit byte to 16-bit word embodiment of a multiply-add instruction  142  ( FIG. 1 ). For one alternative embodiment of the multiply-add instruction, bytes in one of the sources may be signed and in the other they may be unsigned. While in some specific examples, packed data sources and destinations may be represented as having 64-bits, it will be appreciated that the principals disclosed herein may be extended to other conveniently selected lengths, such as 80-bits, 128-bits or 256-bits. 
   For one alternative embodiment, a source register with unsigned data is also the destination register with the 16-bit multiply-add/subtract results. One reason for such a choice is that in many implementations, pixel data may be unsigned and coefficients may be signed. Accordingly, it may preferable to overwrite the pixel data because the pixel data is less likely to be needed in future calculations. 
   Operation control  800  outputs signals on Enable  880  to control operations performed by packed multiply-adder/subtracter  801 . One embodiment of operation control  800  may comprise, for example, a decoder  165  and an instruction pointer register  211 . Of course, operation control  800  may also comprise additional circuitry which is not necessary to understanding the invention. Packed multiply-adder/subtracter  801  includes: 8×8 multiply  802  through 8×8 multiply  809 . 8×8 multiply  802  has 8-bit inputs A 0  of Source1  831  and B 0  of Source2  833 . 8×8 multiply  803  has 8-bit inputs A 1  and B 1 . 8×8 multiply  804  has 8-bit inputs A 2  and B 2 . 8×8 multiply  805  has 8-bit inputs A 3  and B 3 . 8×8 multiply  806  has 8-bit inputs A 4  and B 4 . 8×8 multiply  807  has 8-bit inputs A 5  and B 5 . 8×8 multiply  808  has 8-bit inputs A 6  and B 6 . 8×8 multiply  809  has 8-bit inputs A 7  and B 7 . The 16-bit intermediate results generated by 8×8 multiply  802  and 8×8 multiply  803  are received by adder  852 , the 16-bit intermediate results generated by 8×8 multiply  804  and 8×8 multiply  805  are received by adder  854 , the 16-bit intermediate results generated by 8×8 multiply  806  and 8×8 multiply  806  are received by adder  856  and the 16-bit intermediate results generated by 8×8 multiply  808  and 8×8 multiply  809  are received by adder  858 . 
   Based on whether the current instruction is a multiply/add or multiply/subtract instruction, adder  852  through adder  858  add or subtract their respective 16-bit inputs. The output of adder  852  (i.e., bits  15  through  0  of the Result), the output of adder  854  (i.e., bits  31  through  16  of the Result), the output of adder  856  (i.e., bits  47  through  32  of the Result) and the output of adder  858  (i.e., bits  63  through  48  of the Result) are combined into a 64-bit packed result and communicated to Result[63:0]  890 . 
   Alternative embodiments of byte multiply-add/subtract instructions may include but are not limited to operations for unsigned packed bytes in both sources and operations for signed packed bytes in both sources. Some embodiments of multiply-add/subtract instructions may saturate results while some alternative embodiments may truncate results. 
     FIG. 8   b  illustrates a circuit for performing multiply-add and/or multiply-subtract operations on packed word data according to an alternative embodiment of the invention. Operation control  800  outputs signals on Enable  880  to control Packed multiply-adder/subtracter  801 . Packed multiply-adder/subtracter  801  has inputs: Source1[63:0]  831 , Source2[63:0]  833 , and Enable  880 . Packed multiply-adder/subtracter  801  includes 16×16 multiplier circuits and 32-bit adders. A first 16×16 multiplier comprises booth encoder  823 , which has as inputs Source1[63:48] and Source2[63:48]. Booth encoder  823  selects partial products  826  based on the values of its inputs Source1[63:48] and Source2[63:48]. A second 16×16 multiplier comprises booth encoder  822 , which has as inputs Source1[47:32] and Source2[47:32]. Booth encoder  822  selects partial products  824  based on the values of its inputs Source1[47:32] and Source2[47:32]. For example, in one embodiment of Booth encoder  822 , the three bits, Source1[47:45], may be used to select a partial product of zero (if Source1[47:45] are 000 or 111); Source2[47:32] (if Source1[47:45] are 001 or 010); 2 times Source2[47:32] (if Source1[47:45] are 011); negative 2 times Source2[47:32] (if Source1[47:45] are 100); or negative 1 times Source2[47:32] (if Source1[47:45] are 101 or 110). Similarly, Source1[45:43], Source1[43:41], Source1[41:39], etc. may be used to select their respective partial products  824 . 
   Partial products  824  and partial products  826  are provided as inputs to compression array  825 , each group of partial products being aligned in accordance with the respective bits from Source1 used to generation them. For one embodiment compression array  825  may be implemented as a Wallace tree structure of carry-save adders. For alternative embodiments compression array  825  may be implemented as a sign-digit adder structure. The intermediate results from compression array  825  are received by adder  851 . 
   Based on whether the current instruction is a multiply-add or multiply-subtract instruction, compression array  825  and adder  851  add or subtract the products. The outputs of the adders including adder  851  (i.e., bits  63  through  32  of the Result) are combined into the 64-bit Result and communicated to Result Register  871 . It will be appreciated that alternative embodiments of packed multiplier-adder/subtracter may accept source inputs of various sizes, 128 bits for example. 
     FIG. 8   c  illustrates a circuit for performing multiply-add and/or multiply-subtract operations on packed byte data or packed word data according to another alternative embodiment of the invention. The packed multiply-add/subtract circuit of  FIG. 8   c  has inputs: Source1[63:48], Source2[63:48]. For one embodiment, when multiplexer (MUX)  832  selects Source1[63:56], MUX  834  selects Source1[55:48], and when MUX  836  and MUX  838  select Source2[63:48], a 16×16 multiplication may be performed substantially as described with reference to  FIG. 8   b . On the other hand, when MUX  832  selects Source1[55:48], MUX  834  selects Source1[63:56], MUX  836  selects Source2[63:56] and MUX  838  select Source2[55:48], two 8×8 multiplications may be performed as described below. 
   A 16×16 multiplier comprises encoder  863 , which has as inputs Source1[55:48] from MUX  832  and Source2[55:48] from MUX  838 . Encoder  863  selects partial products for the lower portion of partial products  826 . Source2[55:48] from MUX  838  has eight upper bits padded with zeroes, and so the lower right quadrant of partial products  826  corresponds to partial products for the byte multiplication of Source1[55:48] and Source2[55:48], while the lower left quadrant of partial products  826  contains zeroes. The 16×16 multiplier further comprises encoder  843 , which has as inputs Source1[63:56] from MUX  834  and Source2[63:56] from MUX  836 . Encoder  843  selects partial products for the upper portion of partial products  826 . Source2[63:56] from MUX  836  has eight lower bits padded with zeroes so the upper left quadrant of partial products  826  corresponds to partial products for the byte multiplication of Source1[63:56] and Source2[63:56], while the upper right quadrant of partial products  826  contains zeroes. It will be appreciated that by aligning the partial products as described, addition of the two 16-bit products is facilitated through addition of the partial products. 
   Partial products  826  are provided as inputs to compression array  827 , which provides inputs to full adder  858 . Partial products  826  may be aligned to also facilitate generation of a 32-bit result. Therefore, in such cases, the outputs of full adder  858  corresponding to bits twenty-three through eight contain the 16-bit sum that may be provided to MUX  835 , while the full 32-bit output of full adder  858  may be provided, for example, to full adder  851  when performing multiply-add/subtract operations on packed word data. For one embodiment, the outputs of the adders including adder  858  are optionally saturated to signed 16-bit values (i.e., bits  63  through  48  of the Result) and are then combined into the 64-bit Result and communicated to Result Register  871 . 
   For one embodiment of saturation detection logic  837 , all of the bits corresponding to the result may be examined in order to determine when to saturate. It will be appreciated that alternative embodiments of multiply-add/subtract operations, saturation detection logic  837  may examine less than all of the bits corresponding to the result. 
   From the inputs it is possible to determine the direction of the potential saturation and select a saturation constant to provide to MUX  851 . A signed result has the potential to saturate to a negative hexadecimal value of 8000, only if both products are negative. For example, when one packed byte source has unsigned data elements and the other packed byte source has signed data elements, the negative hexadecimal saturation value of 8000 may be provided as the saturation constant to MUX  851  when both signed data elements, Source2[63:56] and Source2[55:48] for example, are negative. Similarly, since a signed result has the potential to saturate to a positive value, only if both products are positive, the positive hexadecimal saturation value of 7FFF may be provided as the saturation constant to MUX  851  when both signed data elements, Source2[63:56] and Source2[55:48] for example, are positive. 
   For one embodiment of the multiply-add/subtract only particular bit patterns may occur in signed results. Therefore it may be possible for saturation detection logic to identify the particular bit patterns which saturate. For example, using the sum bits, at bit positions  15  and  16  of a 17-bit adder prior to carry propagation and also using the carry-out of bit position  14 , saturation detection logic may signal MUX  835  to saturate when sum[16:15] are 01, when sum[16:15] are 00 and Cout14 is 1, or when sum[16:15] are 10 and Cout14 is 0. Therefore saturation detection logic  837  may detect saturation before a final result is available from full adder  851 . 
     FIG. 8   d  illustrates another circuit for performing multiply-add and/or multiply-subtract operations on packed byte data or packed word data according to another alternative embodiment of the invention. The packed multiply-add/subtract circuit of  FIG. 8   d  has inputs: Source1[63:48], Source2[63:48]. For one embodiment, when MUX  836  and MUX  838  select Source2[63:48], a 16×16 multiplication may be performed substantially as described with reference to  FIG. 8   b . On the other hand, when MUX  836  selects Source2[55:48] and MUX  838  select Source2[63:56], two 8×8 multiplications may be performed as described below. 
   A 16×16 multiplier comprises encoder  863 , which has as inputs Source1[63:56] and Source2[63:56] from MUX  838 . Encoder  863  selects partial products for the lower portion of partial products  826 . Source2[63:56] from MUX  838  has eight upper bits padded with zeroes, and so the lower right quadrant of partial products  826  corresponds to partial products for the byte multiplication of Source1[63:56] and Source2[63:56], while the lower left quadrant of partial products  826  contains zeroes. The 16×16-multiplier further comprises encoder  843 , which has as inputs Source1[55:48] and Source2[55:48] from MUX  836 . Encoder  843  selects partial products for the upper portion of partial products  826 . Source2[55:48] from MUX  836  has eight lower bits padded with zeroes so the upper left quadrant of partial products  826  corresponds to partial products for the byte multiplication of Source1[55:48] and Source2[55:48], while the upper right quadrant of partial products  826  contains zeroes. It will be appreciated that by aligning the partial products as described, addition of the two 16-bit products is facilitated through addition of the partial products. 
   Partial products  826  are provided as inputs to compression array  827 , which provides inputs to full adder  858 . Full adder  858  output bits twenty-three through eight contain the 16-bit sum that may be provided to MUX  835 , while the full 32-bit output of full adder  858  may be provided, for example, to full adder  851  when performing multiply-add/subtract operations on packed word data. From the inputs it is possible to determine the direction of the potential saturation and select a saturation constant to provide to MUX  851 . Saturation detection logic  837  may detect saturation before a final result is available from full adder  851 . For one embodiment, the outputs of the adders including adder  858  are optionally saturated to signed 16-bit values (i.e., bits  63  through  48  of the Result) are and are then combined into the 64-bit Result and communicated to Result Register  871 . 
     FIGS. 9   a - 9   b  illustrate a flow diagrams of prior art processes for performing unpack operations on packed data. In processing block  901 , decoder  165  decodes the control signal received by processor  109 . Thus, decoder  165  decodes the operation code for an unpack instruction. In processing block  902 , via internal bus  170 , decoder  165  accesses registers  210  in register file  150  given the SRC1  602  and SRC2  603  addresses. Registers  210  provide execution unit  130  with the packed data stored in the SRC1  602  register (Source1), and the packed data stored in SRC2  603  register (Source2). That is, extension registers  210  (or registers  209 ) communicate the packed data to execution unit  130  via internal bus  170 . In processing block  903 , decoder  165  enables execution unit  130  to perform the instruction. If the instruction is an unpack instruction for processing low order byte data of Source1 and Source2, flow passes to processing block  918 . 
   In processing block  918 , the following is performed. Source1 bits seven through zero are stored to Result bits seven through zero. Source2 bits seven through zero are stored to Result bits fifteen through eight. Source1 bits fifteen through eight are stored to Result bits twenty-three through sixteen. Source2 bits fifteen through eight are stored to Result bits thirty-one through twenty-four and so forth, interleaving low order bytes from Source1 and Source2 . . . until Source1 bits sixty-three through fifty-six are stored to Result bits one hundred nineteen through one hundred twelve and Source2 bits sixty-three through fifty-six are stored to Result bits one hundred twenty-seven through one hundred and twenty. 
   If the instruction is an unpack instruction for processing high order byte data of Source1 and Source2, flow passes to processing block  928 . 
   In processing block  928 , the following is performed. Source1 bits seventy-one through sixty-four are stored to Result bits seven through zero. Source2 bits seventy-one through sixty-four are stored to Result bits fifteen through eight. Source1 bits seventy-nine through seventy-two are stored to Result bits twenty-three through sixteen. Source2 bits seventy-nine through seventy-two are stored to Result bits thirty-one through twenty-four and so forth, interleaving high order bytes from Source1 and Source2 . . . until Source1 bits one hundred twenty-seven through one hundred and twenty are stored to Result bits one hundred nineteen through one hundred twelve and Source2 bits one hundred twenty-seven through one hundred and twenty are stored to Result bits one hundred twenty-seven through one hundred and twenty. 
   In processing block  920 , the Result is stored in the DEST register. 
   Similarly, unpack instructions may interleave 16-bit, 32-bit, or 64-bit data from two sources. It will be appreciated that while the current unpack instructions perform useful operations for interleaving data from two sources, other reordering operations may also be desirable. 
     FIG. 10   a  illustrates a flow diagram for one embodiment of a process  1011  for performing shuffle operations on packed byte data. In processing block  1001 , decoder  165  decodes the control signal received by processor  109 . Thus, decoder  165  decodes the operation code for a shuffle instruction. In processing block  1002 , via internal bus  170 , decoder  165  accesses registers  209  in register file  150  given the SRC1  602  and SRC2  603  addresses. Registers  209  provide execution unit  130  with the packed data stored in the SRC1  602  register (Source1), and the packed data stored in SRC2  603  register (Source2). In processing block  1003 , decoder  165  enables execution unit  130  to perform the instruction. If the instruction is a shuffle instruction for processing byte data, flow passes to processing block  1018 . 
   In processing block  1018 , the following is performed. A byte of Source1 data at a position indicated by bits seven through zero of Source2 is stored to Result bits seven through zero. In other words, if bits seven through zero of Source2 hold a hexadecimal value of 04 then the fourth byte (bits thirty-nine through thirty-two) of Source1 is stored to Result bits seven through zero. Likewise a byte of Source1 data at the position indicated by bits fifteen through eight of Source2 is stored to Result bits fifteen through eight, and so forth . . . until a byte of Source1 data at the position indicated by bits sixty-three through fifty-six of Source2 is stored to Result bits sixty-three through fifty-six. 
   In processing block  1020 , the Result is stored in the DEST register. 
     FIG. 10   b  illustrates a flow diagram for an alternative embodiment of a process  1021  for performing shuffle operations on packed byte data. In processing block  1001  through  1003  processing is substantially similar to that of process  1011  if the instruction is a shuffle instruction for processing 64-bits of packed byte data. 
   In processing block  1028 , the following is performed. Unless bit seven of Source2 (the most significant bit of bits seven through zero) is set (equal to 1) the byte of Source1 data at a position indicated by bits seven through zero of Source2 is stored to Result bits seven through zero; otherwise Result bits seven through zero are cleared (set equal to 0). Likewise, unless bit fifteen of Source2 is set, the byte of Source1 data at the position indicated by bits fifteen through eight of Source2 is stored to Result bits fifteen through eight, otherwise Result bits fifteen through eight are cleared; and so forth . . . until finally, unless bit sixty-three of Source2 is set, the byte of Source1 data at the position indicated by bits sixty-three through fifty-six of Source2 is stored to Result bits sixty-three through fifty-six otherwise Result bits sixty-three through fifty-six are cleared. 
   In processing block  1020 , the Result is stored in the DEST register. 
     FIG. 10   c  illustrates a flow diagram for another embodiment of a process  1031  for performing shuffle operations on 128 bits of packed byte data. In processing block  1001 , decoder  165  decodes the control signal received by processor  109 . Thus, decoder  165  decodes the operation code for a shuffle instruction. In processing block  1002 , via internal bus  170 , decoder  165  accesses registers  210  in register file  150  given the SRC1  602  and SRC2  603  addresses. Registers  210  provide execution unit  130  with the packed data stored in the SRC1  602  register (Source1), and the packed data stored in SRC2  603  register (Source2). In processing block  1003 , decoder  165  enables execution unit  130  to perform the instruction. If the instruction is a shuffle instruction for processing 128 bits of packed byte data, flow passes to processing block  1038 . 
   In processing block  1038 , the following is performed. Unless bit seven of Source2 is set, the byte of Source1 data at a position indicated by bits seven through zero of Source2 is stored to Result bits seven through zero, otherwise Result bits seven through zero are cleared. Likewise, unless bit fifteen of Source2 is set, the byte of Source1 data at the position indicated by bits fifteen through eight of Source2 is stored to Result bits fifteen through eight, otherwise Result bits fifteen through eight are cleared; and so forth . . . until finally, the byte of Source1 data at the position indicated by bits one hundred twenty-seven through one hundred and twenty of Source2 is stored to Result bits one hundred twenty-seven through one hundred and twenty, unless bit one hundred twenty-seven of Source2 is set, in which case Result bits one hundred twenty-seven through one hundred and twenty are cleared. 
   Again, in processing block  1020 , the Result is stored in the DEST register. 
     FIG. 11   a  illustrates one embodiment of a circuit  1101  for performing shuffle operations on packed data. Circuit  1101  comprises a first array of byte multiplexers (MUXes) each having as inputs the eight bytes ( 1111 - 1118 ) of Source1 bits sixty-three through zero; a second array of byte multiplexers each having as inputs the eight bytes ( 1121 - 1128 ) of Source1 bits one hundred twenty-seven through sixty-four; a third array of multiplexers each having as inputs a pair of multiplexer outputs, a first from the first array and a second from the second array, and each having an output to produce one of sixteen bytes ( 1151 - 1168 ) of Result bits one hundred twenty-seven through zero; a MUX select decode circuit  1181  to select inputs at each of the MUXes of the first, second and third arrays according to the input it receives from SRC2  1130 . Therefore according to the sixteen byte fields of Source2 from SRC2  1130 , any one of the sixteen bytes ( 1111 - 1118  and  1121 - 1128 ) of Source1 may be selected to be stored as any one of the sixteen bytes ( 1151 - 1168 ) of the Result. 
     FIG. 11   b  illustrates an alternative embodiment of a circuit  1102  for performing shuffle operations on packed data. Like circuit  1101 , circuit  1102  comprises the first array of byte multiplexers each having as inputs the eight bytes ( 1111 - 1118 ) of Source1 bits sixty-three through zero; and the second array of byte multiplexers each having as inputs the eight bytes ( 1121 - 1128 ) of Source1 bits one hundred twenty-seven through sixty-four; but the third array of multiplexers each have as inputs the pair of multiplexer outputs, a first from the first array and a second from the second array, and a zero input to selectively clear an output to produce one of sixteen bytes ( 1151 - 1168 ) of Result bits one hundred twenty-seven through zero. Circuit  1102  further comprises MUX select decode circuit  1182  to select inputs at each of the MUXes of the first, second and third arrays according to the input it optionally receives from SRC2  1130 . Optionally, MUX select decode circuit  1182  also selects inputs at each of an optional second set of multiplexer arrays  1140 , which comprise a fourth array of byte multiplexers each having as inputs the eight bytes ( 1131 - 1138 ) of Source2 bits sixty-three through zero; and a fifth array of byte multiplexers each having as inputs the eight bytes ( 1141 - 1148 ) of Source2 bits one hundred twenty-seven through sixty-four. Therefore the third array of multiplexers each have as optional inputs another pair of multiplexer outputs, a first from the fourth array and a second from the fifth array, to produce any byte from Source1 or from Source2 or a zero as one of sixteen bytes ( 1151 - 1168 ) of Result bits one hundred twenty-seven through zero. Therefore, circuit  1102  may perform other operations, for example unpack operations from two registers, as well as shuffle operations. 
   Matrix Transformation Overview 
     FIG. 12  illustrates one exemplary embodiment of a matrix transformation for processing of content data. The content data may be expressed as 4×4 matrix, for example a two dimensional array of pixel values may be written as shown in  FIG. 12  as follows: 
   
     
       
         
           V 
           = 
           
             [ 
             
               
                 
                   a 
                 
                 
                   b 
                 
                 
                   c 
                 
                 
                   d 
                 
               
               
                 
                   e 
                 
                 
                   f 
                 
                 
                   g 
                 
                 
                   h 
                 
               
               
                 
                   i 
                 
                 
                   j 
                 
                 
                   k 
                 
                 
                   l 
                 
               
               
                 
                   m 
                 
                 
                   n 
                 
                 
                   o 
                 
                 
                   p 
                 
               
             
             ] 
           
         
       
     
   
   The transformation may be expressed as 4×4 matrix of coefficient values, which may be written as follows: 
           X   =     [           q   0           r   0           s   0           t   0               q   1           r   1           s   1           t   1               q   2           r   2           s   2           t   2               q   3           r   3           s   3           t   3           ]           
and the transformation calculation may be expressed as a matrix product of the transformation matrix, the content matrix and the transpose of the transformation matrix, written as follows:
   Z=XVX   T . 
   This application describes a method and apparatus for including in a processor instructions for performing matrix transformations on packed data. One embodiment of a matrix transformation performs the matrix operations from right to left, computing first the matrix product  1220  from the matrix multiplication  1210  as:
 
 Y=VX   T ,
 
and computing next the matrix product  1240  from the matrix multiplication  1230  as:
 
 Z=XY.  
 
   For example, a well known set of equations  1250  for computing the elements of the matrix product  1220  are illustrated in  FIG. 12 . It will be appreciated that the techniques herein described are of a general nature and are applicable to any matrix multiplication or to any chained matrix multiplications and not just those wherein one matrix is the transpose of another matrix. 
     FIG. 13   a  illustrates a flow diagram for embodiments of a process  1301  for performing matrix transformations. It will be appreciated that while process  1301  and other processes herein disclosed are illustrated, for the purpose of clarity, as processing blocks with a particular sequence, some operations of these processing blocks may also be conveniently performed in parallel or their sequence may be conveniently permuted so that the some operations are performed in different orders, or some operations may be conveniently performed out of order. 
   In processing block  1311  a first two rows of byte elements of content data are shuffled responsive at least in part to one or more shuffle instructions. For example, shuffle instructions may be used (as further discussed below with reference to  FIGS. 14   a - 14   b  and  FIG. 15 ) to generate a first packed data and a second packed data respectively including elements of a first two columns and elements of a second two columns of the first two rows of the content data. Processing continues in processing block  1312  where multiply-add operations are performed on the shuffled rows and two rows of a fist matrix. For example, responsive to a first multiply-add instruction (as further discussed below with reference to  FIG. 16   a  and  FIG. 16   b ) a multiply-add operation may be performed on the first packed data and two rows of byte elements of the first matrix to generated a third packed data including sums of product pairs from corresponding byte elements of the first packed data and two rows of byte elements of the first matrix. Responsive to another multiply-add instruction a multiply-add operation may be performed on the second packed data and a second two rows of byte elements of the first matrix to generated a fourth packed data including sums of product pairs from corresponding byte elements of the second packed data and the second two rows of byte elements of the first matrix. Processing continues in processing block  1313  where the corresponding sums of products are added to generate two rows of a first matrix product. For example, corresponding sums of products of the third and fourth packed data may be added responsive to a packed add instruction to generate a packed result containing eight elements of the two rows of matrix  1220 . Alternatively, the shuffle instructions, the multiply-add instructions and the packed add instructions may operate on more or on less data elements than shown in the accompanying examples, thereby generating more or less results and therefore may require less or more repetitions of processing blocks  1311 - 1313 . 
   Accordingly, in processing block  1314  a test is performed to determine if processing of the input rows of the content data is finished and the first matrix product has been generated. If not processing repeats the processing blocks  1311 - 1313 , for example, to generate another packed result containing eight more elements of the two more rows of matrix  1220 . Otherwise processing continues in processing block  1315  where multiply-add operations are performed on the first matrix product produced in one or more iterations of processing block  1313  and on columns of a first row of a second matrix. For example, responsive to a multiply-add instruction (as further discussed below with reference to  FIG. 17 ) multiply-add operations may be performed on a packed result containing two rows of the first matrix product and on two columns of a first row of 16-bit elements of the second matrix to generated a packed data including 32-bit sums of product pairs from corresponding 16-bit elements of the first packed result and two columns of the first row of the second matrix. Responsive to another multiply-add instruction multiply-add operations may be performed on a second packed result containing two more rows of the first matrix product and two more columns of the first row of the second matrix to generated another packed data including 32-bit sums of product pairs from corresponding 16-bit elements of the second packed result and the second two columns of the first row of the second matrix. Processing continues in processing block  1316  where corresponding sums of products produced in processing block  1315  are added to generate a row of elements of a second matrix product. For example a row of matrix  1240  may be produced by adding corresponding 32-bit sums of products of both of the packed data produced in processing block  1315 . In processing block  1317  a test is performed to determine if processing of all the rows of the second matrix product has finished, in which case processing ends. Otherwise processing repeats the processing blocks  1315 - 1316  for the next row of the second matrix. 
     FIG. 13   b  illustrates a flow diagram for alternative embodiments of a process  1302  for performing matrix transformations. In processing block  1321  all rows of byte elements of content data input are shuffled responsive at least in part to one or more shuffle instructions. Processing continues in processing block  1322  where multiply-add operations are performed on the shuffled rows and the fist matrix. Processing continues in processing block  1323  where corresponding sums of product results are added to generate the rows of a first matrix product, for example, matrix  1220 . Processing continues in processing block  1325  where multiply-add operations are performed on column elements first matrix product produced in processing block  1323  and rows of a second matrix. Processing continues in processing block  1326  where corresponding sums of product results produced in processing block  1315  are added to generate rows of a second matrix product, for example, matrix  1240 . 
     FIGS. 14   a - 14   b  illustrate a flow diagram for one embodiment of a process  1311  for shuffling content data in matrix transformations. For the sake of clarity, examples illustrated in  FIGS. 14   a - 14   b ,  FIG. 15 ,  FIGS. 16   a - 16   b  and  FIG. 17  show data ordered from left to right consistent with a memory ordering of matrices shown in  FIG. 12 . It will be appreciated that some register orderings (for example, little-endian) reverse the in-register ordering of elements (addresses increasing from right to left) with respect to their memory ordering (addresses increasing left to right). Never the less, operations illustrated may be carried out in substantially the same manner. 
   In processing block  1401  a first row of byte elements  1410  stored in SRC1 are shuffled according to packed data  1460  stored in SRC2. Unless the most significant bit of a byte element of packed data  1460  is set, data of byte elements  1410  in the byte position indicated by said byte element of packed data  1460  is stored to Result  1411  in the byte position corresponding to said byte element of packed data  1460 , otherwise that Result  1411  byte position is cleared. For example, since the most significant bit of the first byte element (having a hexadecimal value of 00) of packed data  1460  is not set, data of byte elements  1410  in the byte position 00 (the value indicated by the first byte element of packed data  1460 ) is stored to Result  1411  in the first byte position (corresponding to the first byte element of packed data  1460 ). On the other hand, since the most significant bit of the third byte element (having a hexadecimal value of 80) of packed data  1460  is set, the third byte position of Result  1411  (corresponding to the third byte element of packed data  1460 ) is cleared to a hexadecimal value 00. 
   Likewise in processing block  1402 , a second row of byte elements  1430  stored in SRC1 are shuffled according to packed data  1461  stored in SRC2. Unless the most significant bit of a byte element of packed data  1461  is set, data of byte elements  1430  in the byte position indicated by said byte element of packed data  1461  is stored to Result  1431  in the byte position corresponding to said byte element of packed data  1461 , otherwise that Result  1431  byte position is cleared. 
   In processing block  1403 , Result  1411  and Result  1431  are combined, for example in response to a logical OR instruction, or in response to a packed add instruction, or in response to a traditional add instruction, said combination generating packed data  1612 , which comprises shuffled elements from two rows of byte elements  1410  and byte elements  1430 . 
   In processing block  1404 , the first row of byte elements  1420  stored in SRC1 are again shuffled this time according to packed data  1462  stored in SRC2. Once again, unless the most significant bit of a byte element of packed data  1462  is set, data of byte elements  1420  in the byte position indicated by said byte element of packed data  1462  is stored to Result  1421  in the byte position corresponding to said byte element of packed data  1462 , otherwise that Result  1421  byte position is cleared. In processing block  1405 , the second row of byte elements  1440  stored in SRC1 are shuffled according to packed data  1463  stored in SRC2 similarly generating Result  1441 . 
   In processing block  1406 , Result  1421  and Result  1441  are combined to generate packed data  1622 , which comprises other shuffled elements from the two rows of byte elements  1420  and byte elements  1440 . Processing then proceeds to processing block  1601 . 
     FIG. 15  illustrates a flow diagram for an alternative embodiment of a process  1311  for shuffling content data in matrix transformations. In processing block  1501 , a first row of byte elements  1510  stored in SRC1 are unpacked with a second row of byte elements  1520  stored in SRC2 to generate Result  1511  comprising elements from the two rows of byte elements  1510  and byte elements  1520 . 
   In processing block  1404 , the two rows of Result  1511  byte elements stored in SRC1 are shuffled according to packed data  1560  stored in SRC2. Data of Result  1511  in the byte position indicated by a byte element of packed data  1560  is stored to Result  1612  in the byte position corresponding to said byte element of packed data  1560 , Result  1612  thereby comprising shuffled elements from the two rows of byte elements  1510  and byte elements  1520 . Similarly in processing block  1503 , the two rows of Result  1511  byte elements stored in SRC1 are shuffled according to packed data  1561  stored in SRC2. Data of Result  1511  in the byte position indicated by a byte element of packed data  1561  is stored to Result  1622  in the byte position corresponding to said byte element of packed data  1561 , Result  1622  thereby comprising other shuffled elements from the two rows of byte elements  1510  and byte elements  1520 . Processing then proceeds to processing block  1601 . 
     FIGS. 16   a - 16   b  illustrate a flow diagram for one embodiment of processes  1312  and  1313  for using multiply-add to generate a matrix product in matrix transformations. In processing block  1601 , responsive to a multiply-add instruction, multiply-add operations are performed on the first shuffled byte elements  1612  from the two rows of content data and on two rows of byte elements  1640  of matrix  1210  to generated Result  1610  including sums of product pairs from corresponding byte elements of the first shuffled byte elements  1612  and the byte elements  1640 . In processing block  1602 , responsive to another multiply-add instruction, multiply-add operations are performed on the second shuffled byte elements  1622  from the two rows of content data and on two more rows of byte elements  1650  of matrix  1210  to generated Result  1620  including sums of product pairs from corresponding byte elements of the second shuffled byte elements  1622  and the byte elements  1650 . Processing continues in processing block  1603  where the corresponding sums of products of Result  1610  and Result  1620  are added responsive to a packed add instruction to generate two rows of 16-bit elements  1611  of the matrix product  1220 . 
   In processing block  1604 , responsive to a third multiply-add instruction, multiply-add operations are performed on a third shuffled byte elements  1632  from the next two rows of content data and on the first two rows of byte elements  1640  of matrix  1210  to generated Result  1630  including sums of product pairs from corresponding byte elements of the third shuffled byte elements  1632  and the byte elements  1640 . In processing block  1605 , responsive to a fourth multiply-add instruction, multiply-add operations are performed on a fourth shuffled byte elements  1672  from said next two rows of content data and on the second two rows of byte elements  1650  of matrix  1210  to generated Result  1670  including sums of product pairs from corresponding byte elements of the second shuffled byte elements  1672  and the byte elements  1650 . Processing continues in processing block  1606  where the corresponding sums of products of Result  1630  and Result  1670  are added responsive to a packed add instruction to generate two more rows of 16-bit elements  1631  of the matrix product  1220 . 
     FIG. 17  illustrates a flow diagram for another embodiment of processes  1315  and  1316  for using multiply-add to generate a matrix product in matrix transformations. In processing block  1701 , responsive to a multiply-add instruction, multiply-add operations are performed on the first two rows of 16-bit elements  1611  and on two columns of 16-bit elements  1720  of a first row of matrix  1221  to generated Result  1710  including 32-bit sums of product pairs from corresponding 16-bit elements of the first two rows of 16-bit elements  1611  and the 16-bit elements  1720  of matrix  1221 . Responsive to another multiply-add instruction multiply-add operations are performed on the second two rows of 16-bit elements  1631  and on two other columns of 16-bit elements  1740  of the first row of matrix  1221  to generated Result  1730  including 32-bit sums of product pairs from corresponding 16-bit elements of the second two rows of 16-bit elements  1631  and the 16-bit elements  1740  of matrix  1221 . Processing continues in processing block  1703  where corresponding 32-bit sums of products from Result  1710  and from Result  1730  are added to generate a row of elements  1711  of the matrix product  1240 . 
   While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described. For example, countably numerous alternative orderings of content data and of transformation matrices may be employed to effectively use the shuffle instructions and the multiply-add instructions for computing matrix transformations. The description is thus to be regarded as illustrative instead of limiting on the invention. From the discussion above it should also be apparent that especially in such an area of technology, where growth is fast and further advancements are not easily foreseen, the invention may be modified in arrangement and detail by those skilled in the art without departing from the principles of the present invention within the scope of the accompanying claims.