JP6651485B2 - Instruction and logic circuits for processing character strings - Google Patents

Description

  The present disclosure relates to the field of processing devices and associated software and software trains for performing logical and mathematical operations.

  Computer systems are becoming more and more popular in our society. The computing power is increasing the efficiency and productivity of people working in a wide range of occupations. The cost of buying and owning a calculator continues to fall. Thus, more consumers can take advantage of newer and faster computers. Furthermore, many people enjoy using notebook computers because of their flexibility. The portable computer allows the user to easily carry data and work while away from work or traveling. Such scenes are a common sight for sales and managers, and even for students.

  As processor technology advances, newer software is also being developed. This software runs on a computer with advanced processing equipment. Users generally expect and demand higher performance from their computers. This is independent of the type of software used. Such performance problems may arise from the types of instructions and operations actually executed inside the processing device. Certain types of operations take longer to complete than others. This is because of the complexity of the operation or the type of circuit required for the operation, or both. This is the motivation for optimizing the way certain complex operations are performed inside the processing unit.

  Communications applications have driven the advancement of microprocessing devices for over a decade. In fact, the line between computation and communication is becoming increasingly blurred. This is due in part to the use of character strings in communications applications. String applications are widespread in the consumer market. Also, the application of character strings has been widespread on many devices. The device is, for example, from a mobile phone to a personal computer. Such devices require that the character string information be processed even faster. Devices that communicate character strings continue to evolve into devices that compute and communicate. Devices that calculate and communicate have applications in the following forms: That is, Microsoft (registered trademark) Instant Messenger (trademark), an application of electronic mail (for example, Microsoft (registered trademark) Outlook (trademark)), and an application of mobile phone mail. As a result, personal computing and communication experiences in the future are expected to be even richer in their ability to handle strings.

  Accordingly, processing or parsing string information exchanged between computing or communicating devices is becoming increasingly important for current computing and communication devices. Among other things, interpreting a sequence of character information by a communicating or calculating device involves some of the most important operations performed on character string data. In such an operation, the degree of parallelism of the data may be at a high level even if the amount of calculation increases. By utilizing this degree of parallelism, efficient implementation using various data storage devices can be performed. The storage device is, for example, a single instruction multiple data (SIMD) type register. Many current computer architectures also require that: That is, various logical and mathematical operations are performed on a large number of operation targets using a plurality of operations, a plurality of instructions, or a plurality of lower instructions (often referred to as “micro instructions” or “μops”). . This speeds up processing and reduces the number of clock cycles required to perform its logical and mathematical operations.

  For example, an instruction sequence consisting of a number of instructions may be needed to do the following: That is, one or more operations required to interpret a particular word in the string. This operation involves comparing two or more string words represented by various data types within the processing device, system, or computer program. However, such a conventional technique may require a large number of processing cycles, and the processing device or system may consume unnecessary power to obtain a result. Further, in some conventional techniques, only a limited data type may be used as a target of an operation.

  According to one aspect of the present invention, there is provided a machine-readable medium having instructions stored thereon. The instructions, when executed by the machine, cause the machine to compare each data element of a first packed operand with each data element of a second packed operand, and to provide a first result of the comparison. The method including the step of storing is performed.

FIG. 2 is a block diagram of the computer system. The computer system includes a processing device. The processing device includes an execution unit. The execution unit executes the instruction. The instruction performs a character string comparison operation. This instruction is in accordance with one embodiment of the present invention. FIG. 6 is a block diagram of another example computer system according to another embodiment of the present invention. FIG. 11 is a block diagram of a computer system of still another example according to still another embodiment of the present invention. FIG. 2 is a block diagram of a microarchitecture of a processing device according to one embodiment. This embodiment includes a logic circuit. This logic circuit performs one or more character string comparison operations according to the present invention. 4 illustrates a representation of various packed data types in a multimedia register according to one embodiment of the present invention. 4 illustrates a packed data type according to another embodiment. 4 illustrates various signed and unsigned packed data type representations in multimedia registers according to one embodiment of the present invention. FIG. 4 illustrates one embodiment of the form of operation encoding (ie, instruction code). 5 illustrates another form of operation encoding (ie, instruction code). 5 shows yet another form of operation coding. FIG. 3 is a block diagram of a logic circuit. This logic circuit performs at least one character string comparison operation on one or more single precision packed data operation targets according to one embodiment of the present invention. It is a division figure of an arrangement. This array may be used to perform at least one string comparison operation according to one embodiment. 4 illustrates operations that may be performed in one embodiment of the present invention.

  The present invention will be described using examples. The present invention is not limited by the embodiments and the attached drawings.

  Described below are examples of techniques. This technique performs an operation to compare between elements of a character string inside a processing device, a computer system, or a software program. In the following description, numerous specific details are set forth. The details are, for example, the type of the processing device, the circumstances of the microarchitecture, the event, the executable mechanism, and the like. The purpose of describing the details is to provide a deeper understanding of the invention. However, those skilled in the art are aware of the following. That is, the present invention may be practiced without such individual details. In addition, some well-known structures, circuits, etc., do not show details. This is to avoid unnecessarily complicating the present invention.

  The following example is described with reference to a processing device. However, other embodiments can be applied to other types of integrated circuits and logic components. The same techniques and teachings as the present invention can be readily applied to other types of circuits or semiconductor components. Other types of circuits or semiconductor components can also benefit from higher pipeline efficiency and improved performance. The teachings of the present invention can be applied to any processing device or machine that performs data operations. Note that the present invention is not limited to a processing device or a machine that performs 256-bit, 128-bit, 64-bit, 32-bit, or 16-bit data operation. The present invention can be applied to any processing device and machine that needs to operate packed data.

  In the following description, numerous specific details are set forth for purposes of explanation. The purpose of describing the details is to provide a thorough understanding of the invention. However, those skilled in the art will understand the following. That is, these individual details are not required to practice the present invention. In some instances, well-known electrical structures and circuits have not been described in detail. This is to avoid unnecessarily complicating the present invention. In addition, the following description shows examples. The accompanying drawings illustrate various examples. These examples are provided for illustrative purposes. However, these examples should not be construed as limiting the present invention. These examples are only intended to illustrate examples of the present invention. These examples are not intended to provide a comprehensive list of all possible implementations of the present invention.

  In the following examples, instruction handling and distribution will be described in the context of execution units and logic circuits. However, other embodiments of the present invention can be realized by software. In one embodiment, the method of the present invention is implemented on machine-executable instructions. Using this instruction, you can: That is, the general-purpose processing device or the special-purpose processing device is programmed by this instruction, and the steps of the present invention are executed. The present invention may be provided as a computer program or software. The computer program or software may include a machine-readable medium or a computer-readable medium. A machine readable medium or a computer readable medium has instructions stored therein. The instructions may be used to program a calculator (or other electronic device). The processing according to the present invention is performed by this program. Alternatively, the steps of the present invention may be performed by specific hardware components. Specific hardware components include logic circuits with fixed wiring for performing the steps of the present invention. Alternatively, the steps of the present invention may be executed by any combination of programmed computer components and dedicated hardware components. Such software can be stored inside the storage device of the system. Similarly, instructions can be distributed. This dispersion is performed by a network. Alternatively, this distribution is performed using another computer-readable medium.

  Thus, a machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (eg, a computer). Machine-readable media include, but are not limited to, floppy diskettes; optical disks; compact disks; CD-ROMs; magneto-optical disks; ROM; RAM; EPROM; Card; flash storage; transmission over the Internet; electrical, optical, acoustic, or other forms of propagating signal (eg, carrier, infrared, digital, etc.); or the like. Accordingly, computer readable media includes any type of medium and machine readable media suitable for storing or transmitting electronic instructions or information in a form readable by a machine (eg, a computer). Further, the present invention may be downloaded as a computer program. That is, the program may be transferred from a remote computer (for example, a server) and taken into a requesting computer (for example, a client). The transfer of the program may be performed by the following signal. That is, an electrical, optical, acoustic, or other form of data signal. These signals are implemented on a carrier or other propagation medium. These signals pass through a communication connection (eg, a modem connection, a network connection, etc.).

  The design may take different stages. That is, the design extends from the creation to the manufacturing through the simulation. Data representing a design may represent the design in a number of ways. First, the following method is convenient for simulation. That is, the hardware may be expressed using a hardware description language or another function description language. In addition, logic and / or transistor gate level circuit models may be created at some stage in the design process. Further, most designers at some stage reach a level of data that represents the physical placement of various elements in the hardware model. When a conventional semiconductor manufacturing technique is used, the data representing the hardware model may be data specifying whether various layers of the semiconductor mask have various features. An integrated circuit is made using this mask. Any representation in the design may store the data on any form of machine-readable medium. The machine-readable medium may be: That is, an optical or electrical wave, storage device, or magnetic or optical enclosure (eg, a disk) that has been modulated or otherwise generated to transmit such information. Any of these media may "carry" or "show" the design or software information. When transmitting an electrical carrier that indicates or carries a code or design, copying, storing, or retransmitting the electrical signal results in a new copy. Accordingly, the telecommunications facility operator or network provider may make a copy of an entity (ie, a carrier) that implements the techniques of the present invention.

  Recent processing devices process and execute various instructions using a number of different execution units. Not all instructions are created equal. That is, some instructions complete earlier than others. Another instruction may spend an enormous number of clock cycles to complete. The faster the instruction is executed, the better the overall performance of the processing unit. Therefore, it is advantageous to execute as many instructions as possible, as quickly as possible. However, some instructions are much more complex than others. Therefore, it requires more execution time and processor resources than other instructions. Examples of such an instruction include a floating-point instruction, a read / write operation from / to a storage device, and a data movement instruction.

  As more and more computer systems are used for Internet, text-writing, and multimedia applications, over time, processing units have been provided with features to support them. For example, instructions such as single instruction multiple data (SIMD) type integer and floating point instructions, and streaming SIMD extensions (SSE) reduce the total number of instructions required to perform a particular program's work. Thereby, power consumption can be reduced. Such instructions can speed up the performance of software by performing operations on a plurality of data elements in parallel. As a result, performance can be increased in a wide range of applications. Applications include video processing, speech processing, and image and photo processing. The implementation of the SIMD instruction is performed by a micro processor or a similar logic circuit. Such an implementation typically has a number of problems. In addition, SIMD operations are complex and often require additional circuitry. The additional circuit correctly processes and computes the data.

  Currently, there is no SIMD instruction that compares each of at least two data elements to be packed. Without SIMD packed compare instructions as performed in one embodiment of the present invention, multiple instructions and data registers may be required to achieve the same result in an application program. The application program performs, for example, interpretation, compression and decompression, processing, and calculation of a character string. In the embodiments disclosed in the present application, the comparison of “character string” and the comparison of “string” are referred to interchangeably. However, embodiments of the present invention may be applied to any sequence of information (eg, a sequence of characters, a sequence of numbers, or a sequence of other data).

  Thus, at least one string comparison instruction according to embodiments of the present invention can reduce program overhead and required resources. Embodiments of the present invention provide a method for implementing an operation for parsing a character string as an algorithm using SIMD-related hardware. At present, it is somewhat difficult and troublesome to perform an operation for parsing a character string on data in a SIMD register. Some algorithms require more instructions for arranging data for arithmetic operations than the number of critical instructions for performing arithmetic operations. By implementing the embodiment of the character string comparison operation according to the embodiment of the present invention, the number of instructions required to process a character string can be significantly reduced.

Embodiments of the present invention include instructions for implementing one or more operations that compare strings. Operations that compare strings generally relate to comparing data elements from two columns of data. This comparison determines which data element matches. Another variation may be made for a general purpose string comparison algorithm. This algorithm is also disclosed later. In a generalized sense, one embodiment of a string comparison operation applies to individual data elements in two packed operations. The two packed operation targets indicate two columns of data. An example of this string comparison operation can be shown generically as follows:
DEST1 <-SRC1 cmp SRC2;
For one packed SIMD data operation target, this general-purpose operation can be applied to the position of each data element of each operation target.

  In the above operation, “DEST” and “SRC” are general terms indicating the destination and source of the corresponding data or operation. In an embodiment, the present invention can be implemented by a register or a memory, or another storage area having a name and function different from those illustrated. For example, in one embodiment, DEST1 is a temporary storage register or other storage area, and SRC1 and SRC2 are destination first and second storage registers or other storage areas. In other embodiments, the SRC and DEST storage areas correspond to different data storage elements in the same storage area (eg, SIMD registers).

  Further, in one embodiment, the string comparison operation generates an indicator of whether each element of one source register is equal to each element of another source register, and stores the indicator in a register such as DEST1. In one embodiment, the indicator is an index value. In another embodiment, the indicator is a mask value. In other embodiments, the indicators represent other data structures or pointers.

  FIG. 1A is a block diagram illustrating an example of a computer system. The computer system has a processor. The processor includes an execution unit that executes a string comparison operation instruction according to one embodiment of the invention. System 100 includes components such as a processor 102 that utilize an execution unit that includes logic for executing algorithms that process data in accordance with the invention, such as the embodiments described herein. System 100 is a PENTIUM® III, PENTIUM® 4, Xeon®, Itanium®, XScale®, StrongARM® registered device available from Intel Corporation of Santa Clara, California. (Trademark). However, other systems (including PCs with other microprocessors, engineering workstations, set-top boxes, etc.) can be used. In one embodiment, the sample system 100 runs a version of the Windows operating system of Microsoft Corporation of Redmond, Wash., While other operating systems (such as Unix, Linux, etc.), embedded software , And / or a graphical user interface. Thus, embodiments of the present invention are not limited to any particular combination of hardware circuits and software.

  Embodiments are not limited to computer systems. Other embodiments of the present invention may be utilized with other devices, such as handheld devices and embedded applications. Examples of handheld devices include cellular phones, Internet protocol devices, digital cameras, personal digital assistants (PDAs), handheld PCs, and the like. For embedded applications, perform string comparison operations on microcontrollers, digital signal processors (DSPs), system-on-chips, network computers (NetPCs), set-top boxes, network hubs, wide area network (WAN) switches, and other operands There is a system. In addition, it incorporates an architecture that increases the efficiency of multimedia applications by executing instructions on multiple data simultaneously. As data types and volumes grow, computers and their processors must be enhanced to manipulate the data in a more efficient manner.

  FIG. 1A is a block diagram of a computer system 100 having a processor 102. Processor 102 includes one or more execution units 108 that execute algorithms that compare data elements of one or more operands. Although one embodiment is described for a single processor desktop or server system, another embodiment can be utilized with a multiprocessor system. System 100 is an example of a hub architecture. Computer system 100 includes a processor 102 that processes data signals. The processor 102 includes a complex instruction set computer (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor having a combination of a plurality of instruction sets, and other digital signal processors. And any other processor. Processor 102 couples to processor bus 110, which allows data signals to be transmitted between processor 102 and other components of system 100. Elements of system 100 perform conventional functions well known to those skilled in the art.

  In one embodiment, processor 102 includes level one (L1) internal cache memory 104. Depending on the architecture, processor 102 may have a single internal cache or multiple internal cache levels. Alternatively, in other embodiments, the cache memory may be external to processor 102. In other embodiments, the internal cache and the external cache may be combined depending on the specific embodiment and needs. The register file 106 can store different types of data in various registers, including integer registers, floating point registers, status registers, and instruction pointer registers.

Processor 102 also has an execution unit 108, which includes logic for performing integer and floating point operations. Processor 102 also includes a microcode (μcode) ROM that stores microcode for macro instructions. In this embodiment, execution unit 108 includes logic for processing packed instruction set 109. In one embodiment, packed instruction set 109 includes a packed string comparison instruction that compares elements of a plurality of operands. By including the packed instruction set 109 in the instruction set of the general-purpose processor 102, the operations used in many multimedia applications can be performed using the packed data in the general-purpose processor 102, along with the associated circuits that execute the instruction. it can. Thus, by performing operations on packed data using the maximum width of the data bus of the processor, many multimedia applications can be speeded up and executed more efficiently. This eliminates the need to transfer data in small units via the data bus of the processor and perform operations on one data element at a time.
Other embodiments of execution unit 108 may be utilized in microcontrollers, embedded processors, graphics devices, DSPs, and other types of logic circuits. System 100 includes memory 120. The memory 120 is a dynamic random access memory (DRAM) device, a static random access memory (SRAM) device, a flash memory device, or another memory device. Memory 120 can store instructions and / or data represented by data signals that can be executed by processor 102. System logic chip 116 is coupled to processor bus 110 and memory 120. In the illustrated embodiment, system logic chip 116 is a memory controller hub (MCH). Processor 102 can communicate with MCH 116 via processor bus 110. MCH 116 provides a high bandwidth memory path 118 to memory 120 for storage of instructions and data, graphics commands, data, and textures. MCH 116 directs data signals between processor 102, memory 120, and other components of system 100, and bridges data signals between processor bus 110, memory 120, and system I / O 122. In some embodiments, system logic chip 116 provides a graphics port for coupling to graphics controller 112. MCH 116 is coupled to memory 120 through memory interface 118. The graphics card 112 is connected to the MCH 116 by an Accelerated Graphics Port (AGP) interconnect 114.

  System 100 couples MCH 116 to an I / O controller hub (ICH) 130 using a unique hub interface bus 122. ICH 130 connects directly to I / O devices via a local I / O bus. The local I / O bus is a high-speed I / O bus that connects peripheral devices to the memory 120, the chipset, and the processor 102. Examples include audio controllers, firmware hubs (flash BIOS) 128, wireless transceivers 126, data storage 124, legacy I / O controllers including user input and keyboard interfaces, serial expansion ports such as USB (Universal Serial Bus), and networks. There is a controller 134. The data storage device 124 is a hard disk drive, a floppy (registered trademark) disk drive, a CD-ROM device, a flash memory device, or another large-capacity storage device.

  For other embodiments of the system, an execution unit that executes an algorithm including a string comparison instruction is available on a system on a chip. One embodiment of a system on a chip is a processor and a memory. The memory of such a system is a flash memory. The flash memory may be on the same die as the processor and other system components. Also, other logic blocks, such as a memory controller or a graphics controller, may be on the system-on-chip.

  FIG. 1B shows a data processing system 140 embodying the principles of one embodiment of the present invention. Those skilled in the art will appreciate that the embodiments described herein may be utilized in alternative processing systems without departing from the scope of the invention.

  Computer system 140 has a processing core 159 that can perform SIMD operations including string comparison operations. In one embodiment, processing core 159 represents a processing unit of any type of architecture, including, but not limited to, each type of architecture such as CISC, RISC, VLIW, and the like. Processing core 159 is suitable for production in one or more process technologies, and can be represented in machine-readable media in sufficient detail to facilitate production.

  The processing core 159 has an execution unit 142, a set of register files 145, and a decoder 144. Processing core 159 also includes other circuitry (not shown), which is not necessary for understanding the present invention. Execution unit 142 is used to execute instructions received by processing core 159. The execution unit 142 recognizes instructions in the packed instruction set 143 in addition to recognizing general processor instructions and performs operations on packed data format. Packed instruction set 143 includes instructions that support string comparison operations, and may include other packed instructions. Execution unit 142 is coupled to register file 145 by an internal bus. The register file 145 represents a storage area on the processing core 159 for storing information including data. As described above, the storage area used to store the packed data is not essential. Execution unit 142 is coupled to decoder 144. The decoder 144 is used to decode the instructions received by the processing core 159 into control signals and / or microcode entry points. The execution unit 142 performs an appropriate operation according to these control signals and / or microcode entry points.

  Processing core 159 is coupled to bus 141 for communicating with various other system devices. The system devices include a synchronous DRAM (SDRAM) control 146, a static RAM (SRAM) control 147, a burst flash memory interface 148, a PCMCIA / compact flash (registered trademark) (CF) card control 149, and a liquid crystal display (LCD) control 150. , DMA controller 151, and alternate bus master interface 152, but are not limited thereto. In one embodiment, data processing system 140 also has an I / O bridge 154 for communicating with various I / O devices via I / O bus 153. I / O devices include, but are not limited to, UART 155, USB 156, Bluetooth® Wireless UART 157, and I / O expansion interface 158, for example.

  One embodiment of the data processing system 140 is a mobile, network and / or wireless communication and processing core 159 that can perform SIMD operations, including string comparison operations. Processing core 159 can be programmed with various audio, video, imaging, and communication algorithms. These algorithms include, for example, Walsh-Hadamard transform, fast Fourier transform, discrete cosine transform (DCT), their respective inverse transforms; compression and decompression methods such as color space transform, video encode motion prediction, or video decode motion. Compensation; includes modulation / demodulation (MODEM) functions such as pulse code modulation (PCM).

  FIG. 1C illustrates yet another embodiment of a data processing system capable of performing a SIMD string comparison operation. The data processing system 160 according to another embodiment includes a main processor 166, a SIMD co-processor 161, a cache memory 167, and an input / output system 168. Input / output system 168 is optionally coupled to wireless interface 169. The SIMD co-processor 161 can execute a SIMD operation including a string comparison operation. The processing core 170 is suitable for production in one or more process technologies and can be represented in sufficient detail on a machine-readable medium to facilitate the production of all or a portion of the data processing system 160 including the processing core 170. Become.

  In one embodiment, the SIMD co-processor 161 has an execution unit 162 and a set of register files 164. One embodiment of the main processor 165 has a decoder 165 that recognizes instructions in the instruction set 163, including SIMD string comparison instructions, which are executed by the execution unit 162. In another embodiment, SIMD co-processor 161 has at least a portion of decoder 165B and decodes instructions of instruction set 163. Processing core 170 also includes other circuitry (not shown), which is not necessary for understanding embodiments of the present invention.

  In operation, main processor 166 executes streams of data processing instructions that control general types of data processing operations, including interactions with cache memory 167 and input / output systems 168. SIMD co-processor instructions are embedded in the data processing instruction stream. The decoder 165 of the main processor 166 recognizes the SIMD coprocessor instruction as being of a type that the associated SIMD coprocessor 161 should execute. Accordingly, main processor 166 issues these SIMD co-processor instructions (or control signals representing SIMD co-processor instructions) on co-processor bus 166, and the associated SIMD co-processor issues co-processor bus 166. Receive co-processor instructions from. In this case, SIMD coprocessor 161 receives and executes the SIMD coprocessor instruction destined for it.

  Data processed by the SIMD co-processor instructions may be received via the wireless interface 169. As an example, a voice communication is received in the form of a digital signal and processed with SIMD co-processor instructions to reproduce digital audio samples representing the voice communication. As another example, compressed audio and / or video may be received in the form of a digital bitstream and processed with SIMD co-processor instructions to play the digital audio samples and / or motion video frames. In one embodiment of processing core 170, main processor 166 and SIMD co-processor 161 are integrated on a single processing core 170. Processing core 170 has an execution unit 162, a set of register files 164, and a decoder 165, and recognizes instructions in instruction set 163, including SIMD string compare instructions.

  FIG. 2 is a block diagram illustrating the micro-architecture of the processor 200. Processor 200 includes logic for executing a string compare instruction according to one embodiment of the present invention. In one embodiment of the string compare instruction, each data element of the first operand is compared to each data element of the second operand, and an indicator is stored that indicates whether each comparison result matches. In the embodiment, a string comparison instruction can be performed on a data element whose size is byte, word, double word, quadword, or the like, and whose data type is an integer or a floating point. In one embodiment, an in-order front end 201 is part of the processor 200 and fetches macro instructions for execution and prepares them for later use in the processor pipeline. The front end 201 includes a plurality of units. In one embodiment, instruction prefetcher 226 fetches macro instructions from memory and feeds them to instruction decoder 228. The instruction decoder 228 decodes the macro instruction into primitives called machine-executable micro-instructions or micro-operations (also called micro-ops or μops). In one embodiment, trace cache 230 takes the decoded micro-operations and places them in micro-operation queue 234 for assembling and executing program ordered sequences or traces. When trace cache 230 encounters a complex macro instruction, microcode ROM 232 provides the micro-operations needed to complete the operation.

  Many macro instructions are translated into a single micro-operation, while other macro instructions require several micro-operations to complete the operation completely. In one embodiment, if more than four micro-operations are required to complete a macro instruction, decoder 228 accesses microcode ROM 232 to execute the macro instruction. In one embodiment, the packed string compare instruction is decoded into a small number of micro-operations and processed by instruction decoder 228. In other embodiments, the packed string comparison algorithm may be stored in microcode ROM 232 if the operation requires a large number of micro-operations. Trace cache 230 is a programmable logic array (PLA) of entry points that determines the correct microinstruction pointer for reading the microcode sequence of the string comparison algorithm in microcode ROM 232. When the microcode ROM 232 finishes sequencing the micro-operations of the current macro instruction, the front end 201 of the machine resumes fetching the micro-operations from the trace cache 230.

  Some SIMD and other multimedia type instructions are considered to be complex instructions. Most floating point instructions are also complicated instructions. Thus, when a complex macro instruction arrives, the instruction decoder 228 accesses an appropriate location in the microcode ROM 232 and reads the microcode sequence of the macro instruction. The various micro-operations required to execute the macro instruction are sent to an out-of-order execution engine 203 for execution in the appropriate integer and floating point execution units.

  The out-of-order execution engine 203 is preparing to execute a microinstruction. The out-of-order execution logic has a large number of buffers and smoothly reorders the flow of microinstructions to optimize execution as the microinstructions go down the pipeline and execution is scheduled. The allocator logic allocates the machine buffers and resources needed to perform each micro operation. Register renaming logic renames the logic register to an entry in the register file. The allocator consists of one of two micro operation queues, one for memory operation and one for non-memory operation, that precede the instruction scheduler memory scheduler, high speed scheduler 202, low speed / general floating point scheduler 204, and simple floating point scheduler 206. Allocate an entry for each micro operation. The micro-operation scheduler 202, 204, 206 may determine, based on the readiness of the input register operand source on which the micro-operation depends, and the availability of execution resources required by the micro-operation to complete the operation, Determine when micro-operations can be performed. The fast scheduler 202 of this embodiment can schedule every half of the main clock cycle, while other schedulers can schedule only every main processor clock cycle. A plurality of schedulers arbitrate the dispatch ports to schedule the execution of micro-operations.

  The register files 208, 210 are between the schedulers 202, 204, 206 and the execution units 212, 214, 216, 218, 220, 222, 224 of the execution block 211. There are separate register files 208 and 210 for integer arithmetic and floating point arithmetic, respectively. In other embodiments, the integer and floating point registers may be in the same register file. Each register file 208, 210 of the present embodiment includes a bypass network that bypasses or transfers just completed results that have not yet been written to the register file to a new dependent micro-operation. The integer register file 208 and the floating point register file 210 can exchange data with each other. In one embodiment, the integer register file 208 is separated into two separate register files, one for the lower 32 bits and one for the upper 32 bits. In one embodiment, the floating point register file 210 has 128 bit wide entries. This is because floating point instructions typically have operands that are 64 to 128 bits wide.

  Execution block 211 includes execution units 212, 214, 216, 218, 220, 222, and 224, which execute the instructions. This section includes the register files 208 and 210. The register files 208 and 210 store the values of the integer and floating-point data operands necessary for executing the microinstruction. The processor 200 of this embodiment includes a plurality of execution units, that is, an address generation unit (AGU) 212, AGU 214, high-speed ALU 216, high-speed ALU 218, low-speed ALU 220, floating-point ALU 222, and floating-point move unit 224. In the present embodiment, the floating point execution blocks 222 and 224 execute a floating point operation, an MMX operation, a SIMD operation, and an SSE operation. The floating-point ALU 222 according to the present embodiment includes a 64-bit to 64-bit floating-point divider, and performs division, square root, and remainder micro operations. In embodiments of the present invention, operations involving floating point values are performed in floating point hardware. For example, conversion between integer format and floating point format involves a floating point register file. Similarly, floating point division operations are performed in floating point dividers. On the other hand, non-floating point types and integer types are handled by integer hardware resources. Simple and frequent ALU operations go to the fast ALU execution units 216, 218. The high-speed ALUs 216 and 218 according to the present embodiment can execute high-speed operations in which the effective latency is half a clock cycle. In one embodiment, most complex integer operations go to the slow ALU 220. This is because the low-speed ALU 220 includes integer execution hardware for long-latency type operations such as multiplication, shift, flag logic, and branch processing. The memory load / store instruction is executed by the AGUs 212 and 214. This embodiment has been described assuming that integer ALUs 216, 218, and 220 perform integer operations on 64-bit data operands. In another embodiment, ALUs 216, 218, 220 may be implemented to support various data bits, such as 16, 32, 128, 256, and the like. Similarly, floating point units 222 and 224 may be implemented to support a range of operands having bits of various widths. In one embodiment, the floating point units 222, 224 can operate on 128-bit wide packed data operands along with SIMD and multimedia instructions.

  In the present embodiment, the micro operation schedulers 202, 204, 206 dispatch dependent operations before the execution of the parent load ends. Because micro-operations are speculatively scheduled in processor 200, processor 200 also includes logic to handle memory misses. If the data load misses in the data cache, there is a dependent operation in the pipeline where the data is temporarily incorrect. The replay mechanism tracks instructions that use incorrect data and re-executes them. Only the dependent operation needs to be replayed, and the independent operation can be completed. The scheduler and replay mechanism of one embodiment of the processor is designed to capture the instruction sequence of the string comparison operation.

  The term "register" refers to a location on an onboard processor that is used as part of a macro instruction that specifies an operand. In other words, a register here is a register that is visible from outside the processor (from a programmer's point of view). However, the register of one embodiment should not be limited to mean any particular type of circuit. Rather, the registers of the embodiments need only be able to store and supply data and perform the functions described herein. The registers described herein may employ any number of different technologies, including dedicated physical registers, dynamically allocated physical registers using register renaming, and combinations of dedicated and dynamically allocated physical registers. And can be implemented by circuitry within the processor. In one embodiment, the integer register stores 32 bits of integer data. The register file of one embodiment also includes eight multimedia SIMD registers for packed data. In the following description, registers are referred to as microprocessor 64-bit wide MMX® registers (sometimes referred to as “mm” registers), implemented with MMX technology from Intel Corporation of Santa Clara, California. It is assumed that the data register is a data register designed to hold packed data. These MMX registers come in integer and floating point formats, but can be used for packed data elements with SIMD and SSE instructions. Similarly, a 128-bit wide XMM register for SSE2, SSE3, SSE4 or higher technology (collectively referred to as "SSEx") may also be used to hold such packed data operands. In the present embodiment, when storing packed data or integer data, the register need not distinguish between the two data types.

  In the embodiment of the following figures, a plurality of data operands will be described. FIG. 3A is a diagram illustrating various packed data types in a multimedia register according to an embodiment of the present invention. FIG. 3A illustrates a packed byte 310, a packed word 320, and a packed doubleword 330 for a 128-bit wide operand. The packed byte format 310 of the present embodiment is 128 bits long and includes 16 packed byte data elements. Here, one byte is defined as 8-bit data. The information of each byte data element is that byte 0 is from bit 7 to bit 0, byte 1 is from bit 15 to bit 8, byte 2 is from bit 23 to bit 16, and finally byte 15 is from bit 127 to bit 120 Is stored by In this way, all bits of the register are used. With such a storage configuration, the storage efficiency of the processor is increased. Also, since 16 data elements are accessed, one operation can be performed on 16 data elements in parallel.

  In general, a data element is an individual piece of data stored in a single register or memory location and has the same length as other data elements. In packed data sequences related to SSEx technology, the number of data elements stored in the XMM register is 128 bits divided by the bit length of each data element. In packed data sequences related to MMX and SSE technologies, the number of data elements stored in the MMX register is 64 bits divided by the bit length of each data element. Although the data type shown in FIG. 3A is 128 bits long, embodiments of the present invention can operate with 64-bit wide or other size operands. The packed word format 320 of this embodiment is 128 bits long and includes eight packed word data elements. Each packed word contains 16 bits of information. The packed doubleword format 330 of FIG. 3A is 128 bits long and includes four packed doubleword data elements. Each packed doubleword data element contains 32 bits of information. A packed quadword is 128 bits long and contains two packed quadword data elements.

  FIG. 3B is a diagram showing another data storage format in a register. Each packed data may include two or more independent data elements. Three packed data formats are shown: packed half 341, packed single 342, and packed double 343. One embodiment of packed half 341, packed single 342, and packed double 343 is a fixed point data element. In another embodiment, packed half 341, packed single 342, and packed double 343 may include floating point data elements. Another embodiment of packed half 341 is 128-bit long data containing eight 16-bit data elements. One embodiment of packed single 342 is 128 bits long and includes four 32-bit data elements. One embodiment of packed double 343 is 128 bits long and includes two 64-bit data elements. Of course, such a packed data format can be extended to register lengths of, for example, 96 bits, 160 bits, 192 bits, 224 bits, 256 bits, or more.

  FIG. 3C is a diagram illustrating various signed and unsigned packed data types in a multimedia register according to an embodiment of the present invention. The unsigned packed byte representation 344 shows the storage of unsigned packed bytes in SIMD registers. The information of each byte data element is that byte 0 is from bit 7 to bit 0, byte 1 is from bit 15 to bit 8, byte 2 is from bit 23 to bit 16, and finally byte 15 is from bit 127 to bit 120 Stored by In this way, all bits of the register are used. With such a storage configuration, the storage efficiency of the processor is increased. Also, since 16 data elements are accessed, one operation can be performed on 16 data elements in parallel. Signed packed byte representation 345 indicates the storage of signed packed bytes. The eighth bit of each byte data element is a sign indicator. The unsigned packed word representation 346 shows how words 7 through 0 are stored in SIMD registers. Signed packed word representation 347 is similar to unsigned packed word register representation 346. The 16th bit of each word data element is a sign indicator. The unsigned packed doubleword data representation 348 illustrates how doubleword data elements are stored. Signed packed doubleword representation 349 is similar to unsigned packed doubleword register representation 348. The required sign bit is the 32nd bit of each doubleword data element. In one embodiment, the operand may be a constant and is not changed by the instruction with which it is associated.

  FIG. 3D illustrates one embodiment of an operation encoding (opcode) format 360. This is 32 bits or more, and the addressing mode of the register / memory operand corresponds to the type of the opcode format described in “IA-32 Intel Architecture Software Developer's Manual Volume 2: Instruction Set Reference”. This manual is available on the World Wide Web at intel.com/design/litcentr from Intel Corporation of Santa Clara, California. In one embodiment, the string comparison operation is encoded in one or more fields 361 and 362. Up to two operands per instruction are located, including up to two source operand identifiers 364 and 365. In one embodiment of the string compare instruction, the destination operand identifier 366 is the same as the source operand identifier 364, and is different in other embodiments. In another embodiment, destination operand identifier 366 is the same as source operand identifier 365, and is different in other embodiments. In one embodiment of the string compare instruction, one of the source operands identified by source operand identifiers 364 and 365 is overwritten by the result of the string compare instruction. On the other hand, in other embodiments, identifier 364 corresponds to a source register element and identifier 365 corresponds to a destination register element. In one embodiment of the string compare instruction, operand identifiers 364 and 365 are used to identify 32-bit or 64-bit source and destination operands.

  FIG. 3E illustrates another operation encoding (opcode) format 370 of 40 bits or more. Opcode format 370 corresponds to opcode format 360 and includes an optional prefix byte 378. The type of string comparison operation is encoded in one or more fields 378, 371 and 372. The location of up to two operands per instruction is specified by source operand identifiers 374 and 375 and prefix byte 378. In one embodiment of the string compare instruction, the prefix byte 378 is used to identify 32-bit, 64-bit, or 128-bit source and destination operands. In one embodiment of the string compare instruction, the destination operand identifier 376 is the same as the source operand identifier 374, and is different in other embodiments. In another embodiment, destination operand identifier 376 is the same as source operand identifier 375, and is different in other embodiments. In one embodiment, the string comparison operation compares each element of the operand identified by operand identifiers 374 and 375 with each element of the other operand identified by operand identifiers 374 and 375, and compares each element with the string comparison operation. Overwrite with the result of On the other hand, in other embodiments, the string comparison of the operand identified by identifiers 374 and 375 is written to another data element of another register. In opcode formats 360 and 370, MOD fields 363 and 373, and register-to-register, memory-to-register, memory-to-register, register-to-register, and register-to-register, are partially defined by the optional scale index base and displacement bytes. Addressing from a register to a memory by an immediate is possible.

  Referring now to FIG. 3F, in another embodiment, a 64-bit single instruction multiple data (SIMD) arithmetic operation is performed by a co-processor data processing (CDP) instruction. Operation encoding (opcode) format 380 indicates such a CDP instruction having CDP opcode fields 382 and 389. In another embodiment of the string comparison operation, the type of the CDP instruction is encoded in one or more fields 383, 384, 387 and 388. Up to three operands can be specified per instruction, including up to two source operand identifiers 385 and 390 and one destination operand identifier 386. One embodiment of the co-processor can operate on 8, 16, 32 and 64 bit values. In one embodiment, the string comparison operation is performed on integer data elements. In embodiments, the string comparison instruction may be conditionally executed using condition field 381. Depending on the string comparison instruction, the source data size can be encoded by field 383. In the embodiment of the string comparison instruction, zero (Z), negative (N), carry (C), and overflow (V) can be detected in the SIMD field. Depending on the instruction, the type of saturation may be encoded in field 384.

  In one embodiment, a field or "flag" may be used to indicate that the result of the string comparison operation is non-zero. In some embodiments, other fields may be used, such as a flag indicating that the source element is invalid, or a flag indicating the LSB or MSB of the result of the string comparison operation.

  FIG. 4 is a block diagram illustrating one embodiment of logic for performing a string comparison operation on packed data operands according to the present invention. Embodiments of the present invention can be implemented to work with various types of operands as described above. In one embodiment, the string comparison operation according to the present invention is implemented as an instruction set that operates on a particular data type. For example, it provides a packed string compare instruction that performs a comparison of 32-bit data types including integer and floating point. Similarly, a packed string compare instruction is provided that performs a comparison of 64-bit data types including integer and floating point. The following description and examples describe the operation of a compare instruction that compares data elements regardless of what the data elements represent. For simplicity, some embodiments show the execution of one or more string comparison instructions where the data elements are textual words.

  In one embodiment, the string compare instruction compares each element of the first data operand DATA A 410 with each element of the second data operand DATA B 420 and stores the result of each comparison in the RESULTANT 440 register. In the following description, it is assumed that DATA A, DATA B, and RESULTANT are registers. However, it is not so limited and includes registers, register files, and memory locations. In one embodiment, a text string compare instruction (eg, “PCMPxSTRy”) is decoded into a single micro-operation. In another embodiment, each instruction can be decoded into various numbers of micro-operations that perform text string comparison operations on data operands. In this embodiment, operands 410 and 420 are 128 bits wide information stored in a source register memory having word wide data elements. In one embodiment, operands 410, 420 are held in a 128-bit SIMD register, such as a 128-bit SSEx XMM register. In one embodiment, RESULTANT 440 is also an XMM data register. In other embodiments, RESULTANT 440 may be another type of register, such as an extension register (eg, “EAX”), or may be a memory location. In some embodiments, the operands and registers may be 32, 64, 256 bits in length, and may have byte, doubleword, or quadword sized data elements. Although the data elements in this embodiment are word sized, the same concept can be extended to byte and double word sized elements. In one embodiment, if the data operand is 64 bits wide, an MMX register is used instead of an XMM register.

  In one embodiment, the first operand 410 is composed of eight data elements A7, A6, A5, A4, A3, A2, A1 and A0. Each comparison between the elements of the first and second operands may correspond to a position of the data element in the result 440. In one embodiment, the second operand 420 is composed of eight data segments B7, B6, B5, B4, B3, B2, B1, and B0. Here, the data segment has the same length and is composed of one data word (16 bits). However, data elements and data element locations may have granularities other than words. When each data element is a byte (8 bits), a doubleword (32 bits), or a quadword (64 bits), the 128-bit operand has a data element of 16 bytes, 4 doublewords, or 2 quadwords, respectively. . Embodiments of the present invention are not limited to data operands or data segments of a particular length, but may utilize any size appropriate for each embodiment.

  Operands 410 and 420 may be in any of a register, a memory location, a register file, or a combination thereof. The data operands 410, 420 are sent to the string comparison logic 430 of the execution unit of the processor along with the text string comparison instruction. In one embodiment, by the time the instruction arrives at the execution unit, the instruction is decoded early in the processor pipeline. Thus, the string compare instruction may be in the form of a microinstruction (μop) or other decoded format. In one embodiment, two data operands 410, 420 are received by string comparison logic 430. In one embodiment, the text string comparison logic generates an indication whether the elements of the two data operands are equal. In one embodiment, only the valid elements of each operand are compared. The valid elements are indicated by other registers or memory locations for each element of each operand. In one embodiment, each element of operand 410 is compared with each element of operand 420. This comparison produces a comparison result equal to the number of elements of operand 410 multiplied by the number of elements of operand 420. For example, if each operand 410 and 420 is a 32-bit value, result register 440 stores up to 32 × 32 result indicators of text comparison operations performed by string comparison logic 430. In one embodiment, the data elements from the first and second operands are single precision (eg, 32 bits); in another embodiment, the data elements of the first and second operands are double precision (eg, 64 bits). In other embodiments, the first and second operands may include integer elements of any size, including 8, 16, and 32 bits.

  In one embodiment, data elements at all data locations are processed in parallel. In other embodiments, some of the data element locations can be processed simultaneously. In one embodiment, RESULTANT 440 comprises a plurality of results of a comparison between each data element stored in operands 410 and 420. Specifically, in one embodiment, the result (RESULTANT) may store the comparison result of only the square of the number of data elements of one of the operands 410 and 420.

  In one embodiment, RESULTANT stores the comparison result of only the comparison between the valid data elements of operands 410 and 420. In one embodiment, the data element of each operand may be explicitly or implicitly indicated as valid. For example, in one embodiment, each operand data element corresponds to a validity indicator, such as a valid bit, stored in another storage area, such as a valid register. In one embodiment, the validity bits for each element of both operands are stored in the same valid register. However, in other embodiments, the validity bits of one operand are stored in a first valid register and the validity bits of the other operand are stored in a second valid register. Determine whether both data elements are valid (eg, by checking the corresponding valid bit) before and / or with the operand data elements so that the comparison is performed only between valid elements. Is also good.

  In one embodiment, the valid data element for each operand may be implicitly indicated by the use of a null or "zero" field stored in one or both of the operands. For example, in one embodiment, the null byte (or other size) is stored in the element such that all significant data elements are invalid while all non-null data elements are valid. , May be indicated to be compared with corresponding valid data elements of other operands. Further, in one embodiment, the valid data element of one operand may be explicitly indicated (as described above), while the valid data element of the other operand may be implicitly indicated using a null field. In one embodiment, valid data elements are indicated by a count corresponding to the number of valid data elements or sub-elements in one or more source operands.

  Regardless of how the valid data element for each operand is indicated, at least one embodiment compares the data element for each operand that is indicated as valid. Comparison of only valid data elements can be performed in multiple ways in various embodiments. For the purpose of providing a detailed and understandable explanation, a method of comparing only valid data elements between two text string operands can be best conceptually described below. However, the following description is merely one example of how the comparison of only valid data elements of a text string operand is conceptually described or performed below. In other embodiments, other conceptual descriptions and methods are used to show how valid data elements are compared.

  In one embodiment, the number of valid data elements of the operand is explicitly indicated (e.g., by counting the number of valid bits in the validity register, or the number of valid byte words starting from the least significant), or ( Only the valid data elements of each operand are compared to each other, whether implied (for example, by a null character in the operand). In one embodiment, the data elements that are compared to the tally of validity indicators are conceptually described with reference to FIG.

  Referring to FIG. 5, in one embodiment, arrays 501 and 505 include an entry indicating whether each element of the first and second operands is valid, respectively. For example, in the above example, array 501 contains a "1" for each array element whose first operand contains a corresponding valid data element. Similarly, array 505 contains a "1" for each array element whose second operand contains a corresponding valid data element. In one embodiment, arrays 501 and 505 include one starting at array element 0 for each valid element in the two operands. For example, in one embodiment, if the first operand contains four valid elements, the array 501 contains only ones in the first four array elements, and all other array elements in array 501 are zero.

  In one embodiment, arrays 501 and 505 are 16 elements in size and represent 16 data elements of two 128-bit operands, each 8 bits (1 byte) in size. In another embodiment, the data element size of the operand is 16 bits, and arrays 501 and 505 contain only 8 elements. In other embodiments, arrays 501 and 505 may be larger or smaller depending on the size of the corresponding operand.

  In one embodiment, each data element of the first operand is compared to each data element of the second operand, and the result is represented by an i × j array 510. For example, a first data element of a first operand representing a text string is compared to, for example, each data element of another operand representing another text string and stored in each array element in a first row of array 510. The assigned "1" corresponds to a match between the first data element of the first operand and each data element of the second operand. This is repeated for each data element of the first operand until array 510 is completed.

  In one embodiment, a second array 515 of i × j entries is generated to store an indication whether only valid operand data elements are equal. For example, in one embodiment, each entry in the first row 511 of the array 510 is logically ANDed with the corresponding valid array element 506 and the valid array element 502 and the result is compared with the corresponding element 516 of the array 515. To place. An AND operation may be performed between each element of array 510 and the corresponding element of valid arrays 501 and 505, and the result placed in the corresponding element of array 520.

  In one embodiment, result array 520 indicates whether any of the data elements of one operand are related to data elements of another operand. For example, result array 520 performs an AND operation on a pair of elements of array 515 and ORs all the results of the AND to store a bit indicating whether the data element is within a range determined by the data element of the other operand. can do.

  FIG. 5 also shows a result array 520 that stores various indicators for comparisons between data elements of at least two packed operands. For example, result array 520 stores a bit indicating whether there is an equal data element between the two operands by ORing the corresponding elements of array 515. If any of the array elements of the array 515 include, for example, a "1" indicating that there is a match between valid data elements of the operands, this is reflected in the result array 520. Elements of the result array 520 may be ORed to determine whether the valid data elements of the operands are equal.

  In one embodiment, detecting a contiguous "1" in the array detects a sequence of valid matches between the data elements of the two operands in the result array 520. In one embodiment, this can be achieved by ANDing successive result array elements at one time and ANDing the result of one AND operation with the next result until a "0" is detected. In other embodiments, other logic may be used to detect a valid match range of the data elements of the two packed operations.

  In one embodiment, result array 520 may indicate whether each data element of both operands matches by returning a "1" to the corresponding result array entry. An XOR operation may be performed on the result array entries to determine if all entries are equal. In other embodiments, other logic may be used to determine whether the valid data elements of the two operands are equal.

  In one embodiment, the test string is compared to the same sized portion of the other string to determine that the string of the data element is somewhere in the other string of the data element, and the test string and that portion of the other string are compared. Can be detected by showing a match in the result array. For example, in one embodiment, a test string of three characters corresponding to three data elements of a first operand is compared to a first set of three data elements of a second string. When a match is found, the match is reflected in the result array. This is done by storing "1" in the group of three result entries corresponding to the match. Compare the test string with the next three data elements of the other operand. Alternatively, two of the data elements of the previous operand and a new third data element may be compared to the test string such that the test string "slides" along the other operand as it is compared.

  In one embodiment, the result array entries may be inverted or negated, depending on the application. In other embodiments, only some of the result entries are negated, eg, only those that correspond to a valid match between the data elements of the two operands. In other embodiments, other operations may be performed on the result entries of result array 520. For example, in some embodiments, result array 520 is represented as a mask value. In another embodiment, the result array is represented by an index value and stored in a storage location such as a register. The index is represented in one embodiment by the group of MSBs of the result array, and in another embodiment by the LSB of the array. In one embodiment, the index is represented by an offset value to a set LSB or MSB. The mask is a zero extension in one embodiment, a byte / word mask, or other granularity in other embodiments.

  In various embodiments, each of the above differences in comparing each element of the SIMD operand is implemented as a separate instruction. In other embodiments, the above differences may be implemented by changing the attributes of a single instruction, such as immediate fields associated with the instruction. FIG. 6 is a diagram illustrating various operations performed by one or more instructions to compare each data element of two or more SIMD operands. In one embodiment, the operands compared by the operation of FIG. 6 are text strings. In other embodiments, the operand is other data information or data.

  Referring to FIG. 6, in operation 610, the elements of first SIMD operand 601 and second SIMD operand 605 are compared with each other. In one embodiment, one operand is stored in a register, such as an XMM register, and the other operand is stored in another XMM register or memory. In one embodiment, the type of comparison is controlled by an immediate field corresponding to the instruction that performs the operation shown in FIG. For example, in one embodiment, a 2-bit immediate field (e.g., IMM8 [1: 0]) is used to compare data elements with signed bytes, signed words, unsigned bytes, or unsigned bytes. Indicates a word or not. In one embodiment, the comparison results in an ixj array (eg, BoolRes [i, j]), or a portion of the ixj array.

  In operation 613, the end of the string represented by operands 601 and 605, respectively, is found in parallel to determine the validity of each element of operands 601 and 605. In one embodiment, the validity of each element of operands 601 and 605 is explicitly indicated by setting the corresponding bit or bits in a register or memory location. In one embodiment, the one or more bits correspond to the number of consecutive valid data elements (eg, bytes) starting from the LSB position of operands 601 and 605. For example, depending on the size of the operand, a bit such as an EAX register or a RAX register is used to store a bit indicating the validity of each data element of the first operand. Similarly, depending on the size of the operand, a bit indicating the validity of each data element of the second operand is stored using a register such as an EDX register or an RDX register. In other embodiments, the validity of each element of operands 601 and 605 may be implicitly indicated by means already described in this disclosure.

  In one embodiment, in operation 615, the comparison and validity information is combined by an aggregation function to generate a comparison of the elements of the two operands. In one embodiment, the aggregation function is determined by the immediate field associated with the instruction that performs the comparison of the two operand elements. For example, in one embodiment, the data elements of the two operands are equal, the ranges of the data elements of the two operands are equal, the data elements of the two operands are equal, or the sequence of at least some of the data elements of the operands. The immediate field indicates whether are the same or a comparison.

  At operation 620, in one embodiment, the result of the aggregation function (eg, stored in IntRes1) is negated. In one embodiment, bits in the immediate field (eg, IMM8 [6: 5]) control the type of negation function performed on the result of the aggregation function. For example, the immediate field may indicate that the aggregation result is not negated at all, that the results of the aggregation function are all negated, or that only the aggregation result corresponding to the valid element of the operand is negated. In one embodiment, the result of the negation operation is stored in an array (eg, an IntRes2 array).

  In one embodiment, at operations 625 and 630, respectively, the resulting array produced by the negation operation is converted to an index value or a mask value. When the result of the negation operation is converted into an index, whether the MSB or LSB of the comparison result is encoded into the index is determined by a bit (eg, IMM8 [6]) of the immediate field, and the result is registered in a register (eg, ECX or RCX). ) Is controlled. In one embodiment, if the result of the negate operation is represented by a mask value, bits in the immediate field (eg, IMM8 [6]) can be used to zero-extend the mask or use bytes (or Word).

  Thus, a method of performing a string comparison operation is disclosed. While example embodiments are described and illustrated in the accompanying drawings, it should be understood that such embodiments are merely illustrative of the invention and are not limiting, and that various modifications will become apparent to those of skill in the art upon studying the present disclosure. Therefore, the present invention is not limited to the specific configuration shown and described. In this technical field, etc., since growth is fast and progress cannot be easily foreseen, it is facilitated by enabling technical progress without departing from the principle of the present invention and the scope of the appended claims. Embodiments can be easily modified in configuration and details.

In addition, the following supplementary notes are described for the above embodiment.
(Supplementary Note 1) A machine-readable medium storing instructions, wherein the instructions, when executed by a machine, cause the machine to transfer each data element of a first packed operand to each of a second packed operand. Comparing with the data element;
Storing the first result of the comparison.
(Supplementary note 2) The machine-readable medium of Supplementary note 1, wherein only the valid data element of the first operand is compared with only the valid data element of the second operand.
(Supplementary note 3) The machine-readable medium of Supplementary note 1, wherein the first result indicates whether any of the data elements are equal.
(Supplementary note 4) The supplementary note 1, wherein the first result indicates whether the range of data elements indicated in the first operand is equal to the range of data elements indicated in the second operand. Machine readable medium.
(Supplementary note 5) The machine-readable medium of Supplementary note 1, wherein the first result indicates whether each data element of the first operand is equal to each data element of the second operand.
(Supplementary note 6) The machine according to Supplementary note 1, wherein the first result indicates whether the order of some of the data elements of the first operand is equal to the order of some of the data elements of the second operand. Readable media.
(Supplementary note 7) The machine-readable medium of Supplementary note 1, wherein a part of the first result is negated.
(Supplementary note 8) The machine-readable medium according to supplementary note 1, wherein the first result is represented by either a mask value or an index value.
(Supplementary note 9) comparison logic for comparing only the valid data element of the first operand with only the valid data element of the second operand;
A first control signal for controlling the comparison logic.
(Supplementary note 10) The apparatus according to supplementary note 9, wherein the validity of the data elements of the first and second operands is explicitly indicated.
(Supplementary note 11) The apparatus according to supplementary note 9, wherein the validity of the data elements of the first and second operands is implicitly indicated.
(Supplementary note 12) The apparatus according to supplementary note 9, wherein the first control signal includes a sign control signal indicating whether the comparison logic compares signed or unsigned values.
(Supplementary note 13) The first control signal is whether or not the comparison logic performs an aggregation function selected from a list consisting of: equal, equal in range, respectively equal, discontinuous substrings, and equal order. 13. The apparatus of claim 12, including the aggregate function signal shown.
(Supplementary note 14) The apparatus according to supplementary note 13, wherein the first control signal includes a negation signal, and causes the comparison logic to negate at least a part of a result of the comparison.
(Supplementary note 15) The apparatus according to supplementary note 14, wherein the first control signal includes an index signal indicating whether the comparison logic generates an MSB or LSB index of the result of the comparison.
(Supplementary note 16) The apparatus according to supplementary note 15, wherein the first control signal includes a mask signal indicating whether the comparison logic generates a zero extension mask or an extension mask as a result of the comparison.
(Supplementary note 17) The apparatus according to supplementary note 16, wherein the first control signal is a control field that stores a plurality of bits.
(Supplementary Note 18) A first memory storing a single instruction multiple data (SIMD) comparison instruction;
A system comprising: a processor that executes the SIMD comparison instruction and compares data elements of first and second operands indicated by the SIMD comparison instruction.
(Supplementary note 19) The system according to supplementary note 18, wherein the first operand is indicated in the instruction by an address of a first register.
(Supplementary note 20) The system according to supplementary note 19, wherein the second operand is indicated in the instruction by a memory address or a second register.
(Supplementary note 21) The system according to supplementary note 20, wherein the instruction includes an immediate field indicating a control signal to the processor.
(Supplementary note 22) The system according to supplementary note 21, wherein the immediate field indicates whether the operand includes a signed byte, an unsigned byte, a signed word, or an unsigned word.
(Supplementary note 23) The system according to Supplementary note 22, wherein the immediate field indicates that the processor performs an aggregation function.
(Supplementary note 24) The system according to supplementary note 23, wherein the immediate field indicates whether to generate a mask or an index in response to execution of the instruction.
(Supplementary note 25) The system according to supplementary note 18, wherein the instruction causes only the explicitly valid data elements of the first and second operands to be compared.
(Supplementary note 26) The system according to Supplementary note 18, wherein the instruction causes only the implicitly valid data elements of the first and second operands to be compared.
(Supplementary Note 27) A first storage area for storing a first packed operand corresponding to the first text string;
A second storage area for storing a second packed operand corresponding to the second text string;
Comparison logic for comparing all valid data elements of the first packed operand with all valid data elements of the second packed operand;
A third storage area for storing an array of the result of the comparison executed by the comparison logic.
(Supplementary note 28) The comparison logic generates a two-dimensional array of values, where an entry in the array is a valid data element of the first packed operand and a valid data element of the second packed operand. 28. The processor of claim 27 corresponding to a comparison between:
(Supplementary note 29) The comparison logic performs one of an aggregation function consisting of equal to, equal to, equal to each other, non-contiguous substrings, and equal order to the two-dimensional array of values. 29. The processor according to attachment 28.
(Supplementary note 30) The processor according to supplementary note 29, wherein the result array is represented by either a mask value or an index value.

Claims (19)

A processor,
At least one processor core for executing instructions and processing data;
A multi-level cache including a level 1 (L1) cache;
A first packed data source register;
A second packed data source register;
A decoder for decoding an instruction, including a packed compare instruction, wherein a first set of packed integer data elements is stored in said first packed data source register, and a second set of packed integer data elements is: The first set of one or more packed integer data elements stored in the second packed data source register encodes a character, and the second set of packed integer data elements stores a set of ranges. A decoder to encode,
Executing the packed comparison instruction such that a first character encoded by the first set of first packed integer data elements is defined by the second set of packed integer data elements. a running circuit that determines it is within range, to update the result register, and execution circuit to which the first character to provide the information that it is within the range,
A processor having:   The processor of claim 1, wherein the first set of packed integer data elements and the second set of packed integer data elements include packed bytes.   The processor of claim 1, further comprising a microcode read only memory (ROM) for storing microcode of the packed comparison instruction. The first packed data source register and the second packed data source register include a 128 bit packed data register;
The processor according to claim 1.   The processor of claim 1, further comprising an instruction scheduler for scheduling the packed compare instruction for execution by the execution circuit.   The processor of claim 1, wherein the characters include text characters and numeric characters. Storing a first set of packed integer data elements in a first packed data source register;
Storing a second set of packed integer data elements in a second packed data source register;
Decoding an instruction including a packed compare instruction, wherein the first set of one or more packed integer data elements encodes a character, and wherein the second set of packed integer data elements comprises a range of Encoding a set; and executing the packed compare instruction;
In response to execution of the packed comparison instruction, a first character encoded by the first set of first packed integer data elements is defined by the second set of packed integer data elements. Judging whether it is within the range,
Updating a result register to provide information that said first character is within said range;
Including, methods.   The method of claim 7, wherein the first set of packed integer data elements and the second set of packed integer data elements include packed bytes.   The method of claim 7, wherein decoding comprises translating the packed compare instruction using microcode read-only memory (ROM). The first packed data source register and the second packed data source register include a 128 bit packed data register;
The method according to claim 7. Scheduling the packed compare instruction for execution subsequent to decoding.
The method according to claim 7. The characters include text characters and numeric characters,
The method according to claim 7. On the computer,
Storing a first set of packed integer data elements in a first packed data source register;
Storing a second set of packed integer data elements in a second packed data source register;
Decoding an instruction including a packed compare instruction, wherein the first set of one or more packed integer data elements encodes a character, and wherein the second set of packed integer data elements comprises a range of Encoding the set, steps,
Executing the packed comparison instruction;
In response to execution of the packed comparison instruction, a first character encoded by the first set of first packed integer data elements is defined by the second set of packed integer data elements. Judging whether it is within the range,
Updating a result register to provide information that said first character is within said range;
A computer program that executes   14. The computer program of claim 13, wherein the first set of packed integer data elements and the second set of packed integer data elements include packed bytes. Decoding includes converting the packed compare instruction using a microcode read only memory (ROM);
A computer program according to claim 13. The first packed data source register and the second packed data source register include a 128 bit packed data register;
A computer program according to claim 13. On the computer,
14. The computer program of claim 13, further comprising the step of scheduling the packed compare instruction for execution following decoding. The characters include text characters and numeric characters,
A computer program according to claim 13.   A machine-readable medium storing the computer program according to any one of claims 13 to 18.

Images