JP5356531B2 - Instruction optimization performance based on sequence detection or information associated with the instruction - Google Patents

Abstract

In one embodiment, the present invention includes an instruction decoder that can receive an incoming instruction and a path select signal and decode the incoming instruction into a first instruction code or a second instruction code responsive to the path select signal. The two different instruction codes, both representing the same incoming instruction may be used by an execution unit to perform an operation optimized for different data lengths. Other embodiments are described and claimed.

Description

  In most processor-based systems, the processor provides instructions tailored for efficient execution of operations such as copying and storing. Software optimized for memory copy operations is tailored for specific processor implementations. In many cases, the best way to perform a copy of the data changes, so the compiler, operating system (OS) kernel, and application writer have a lot of code tailored to different scenarios, different microarchitectures, etc. The code is like a moving target.

  An iterative copy instruction can be used to copy a certain amount of data elements defined by one of the parameters of the instruction. The iterative copy instruction may have various native data element lengths such as, for example, bytes, words, double words, quadruple words, etc. The longer the native length, the more efficiently the instructions are executed to move a certain amount of data, which may use larger “load” and “store” operations. Because it can. For example, a repeat (repeated) move (move) byte (REP MOVSB) instruction of an Intel (registered trademark) architecture (IA32) structure uses a value in a predetermined register as information indicating the length of a copy. . The instruction also receives a copy source pointer and a copy destination pointer as input parameters. Such an instruction is defined to move one byte of data one at a time. Under certain conditions, operations are performed using long operations (eg, 16 bytes at a time), and in such cases, execution of instructions switches to a “fast mode”. The IA32 programmer's reference manual defines the conditions under which the high speed mode may be executed in the current processor.

  In many cases, at compile time, the length of the copy and the configured operation are unknown, so one solution to improve the effectiveness of the copy operation using the traditional implementation of the iterative copy operation is: First, use a first iterative copy instruction that moves the majority of the string, then use a second iterative copy instruction that moves the rest of the data (eg, the first copy operation moves a doubleword at a time In the second copy operation, the last 0 to 3 bytes are moved). Such a sequence has two drawbacks. (A) By executing the second instruction, even if the remaining part of the data is 0, a further cycle is consumed. (B) Optimization is adjusted for a limited sequence of first iteration copy instructions with a specific length followed by a second instruction, with significant performance loss for other combinations Will occur.

  A pipeline machine also decodes an instruction with the most preferred behavior of the instruction, even though some of the data needed to determine the best behavior is unknown or not yet committed. There may be cases where it needs to be determined at a time. As an example of such a case, there is a case where a branch is selected by a flag even though the flag has not yet been calculated. The most common scheme for solving such problems is to use a branch predictor. However, predictors require training (building history) time, are expensive (because many states need to be saved), and performance under fragmentary patterns is uncertain .

3 is a flowchart of a method according to an embodiment of the present invention. It is a block diagram of the sequence detector which concerns on one Embodiment of this invention. FIG. 4 is a state diagram of an example of a sequence decoder state machine according to an embodiment of the present invention. It is a block diagram of a processor concerning one embodiment of the present invention. 1 is a block diagram of a system according to an embodiment of the present invention.

  In various embodiments, the characteristics of the copy operation generated by the compiler are utilized to make the iterative copy operation more efficient. As used herein, the term “copy” operation is used generically to refer to memory copy operations, memory move operations, and memory set operations that move data into, out of, or out of memory. . Different environments may have different names for these common operations. The “fast mode” of these copy operations can be performed in many cases. Even if it is not feasible (for example, if the aliasing risk test fails), in many cases (assuming a random distribution) one data element is copied at a time. A mode faster than the native mode can be executed. An optimized copy sequence will initially attempt to perform a copy using one of several different fast modes (ie, faster than native mode), but use native length operations. There are only a few cases where copying must be performed. A processor instruction set may include one or more instructions that direct the processor to perform a memory copy operation or a memory set (store) operation, and once these operations are efficiently implemented, the processor hardware , Performance boundaries across different microarchitecture generations and different architecture generations can be maintained.

  As described below, one embodiment may include a number of major steps (described in detail below) that perform (1) a check of the rules necessary to initiate a “fast copy”. , The part that sets the operation for the next stage, (2) the head part where the conditional copy was performed (covers the latency of the pipeline and prevents bubbles caused by propagation by using the conditional operation), (3) It includes a fast fixed size iteration with added features to handle the desired case, and (4) a tail portion. Check and head portions (step 1 and step 2) are performed for the entire string length (ie, copy length or block length). The head portion is executed when all the checks are possible, and if the result of the check is unsuccessful, the hardware enters a native loop that performs a copy operation of a native size at a time. The fast loop and tail portions are executed as needed depending on the length of the copy analyzed at the head portion. By making the decision at an early stage, the execution path is selected using the smallest pipeline bubble and no branch miss is predicted. Additional restrictions may be applied to some of the length or src-dst distance handling, and some implementations of “fast loops” may require some re-execution of operations. Certain non-exact exception detection may be present in addition to the checks performed at the head, is allowed to return up to 64B, and the destination point is behind the source pointer and less than 63B (I.e., (dst mod 4K)-(src mod 4K) <63B) needs to be checked. If such additional checks fail, it is possible to branch to another, but not optimal, code routine for correct execution. Also, some embodiments may handle special cases where the copy operation length is very long and the caching hints can be used to improve performance. Although specific size copy operations are described herein, the scope of the present invention is not limited to these, and embodiments are optimized for other sizes (eg, different number of bytes and cache line width). Handled copy operations.

  FIG. 1 is a flowchart of a method according to an embodiment of the present invention. The method 100 may be performed at various locations on a processor, such as a general purpose hardware unit or a dedicated hardware unit. The method 100 may be used to perform an iterative copy operation in an optimized manner. As shown in FIG. 1, in the method 100, a check is first performed to prepare for a copy operation (block 110). Specifically, various checks are performed to determine the type of copy operation to be performed, and various count values used in the copy operation are read into a counter associated with the copy operation. The counter may be initialized. First of all, some checks may be made to determine if a fast flow in which a copy operation is performed using a read / store operation that is longer than the native length of the instruction is feasible. If any one of the checks fails, a native mode loop is executed and the copy operation is the native length of the instruction, eg, an operation that works in bytes or an instruction in doublewords. (Block 120). A check is made using data obtained in the execution phase where the necessary information is already available and known. If any of the checks fail, there will be an associated performance hit and a misprediction cost, which is a rare case in normal use and is relative when considering the cost of the native loop. Loss is low.

  In one embodiment, the condition to be checked includes checking the distance between the destination (dst) pointer string and the source (src) pointer string, where the previously read src determines the behavior of the operation. Do not change it. The distance is measured by determining whether 0 byte (B) <((dst mod 4K) − (src mod 4K)) <16B. If it is within this range, the mode may be shifted to the native mode. In embodiments where memory aliasing between pages is irrelevant, the operation may be performed without "mod 4K". The direction (DF) flag is also checked. When the DF flag == 1, the mode may be shifted to the native mode. A check for wraparound of the address space (for both src and dst) may be performed, and if the check result is true, the mode moves to native mode. Other implementations may be used by adding other conditions or removing some of the conditions for entering the high speed mode.

  In block 110, for example, a fast loop preparation such as “Fast Loop” is made and the tail portion may also be executed. In one embodiment, this stage calculates a counter for the fast CL loop (eg, the length is specified in bytes in the rcx register, each loop operates at 64 bytes, and the number of iterations is rcx And the value is read into the zero overcounter register (assuming that the "head" portion copies up to 64B of data, as described below, and enters the fast loop 110. The counter is decremented by 1 when jumping). When data with a “head” portion larger than 64B (for example, 128B) is handled, it may be necessary to subtract a constant from the calculated value of rcx / 64. The tail condition is then calculated and placed in the zero overhead jump control register.

  If any of the checks fail, control passes to block 120 and the copy may take place in native mode. In various embodiments, this native mode can be used to perform copy operations according to the native length mode. Here, method 100 may end. Thus, if the conditions necessary to bundle the copy operations are not met, the native length is used for each copy iteration (iteration) using a zero overhead loop (eg, repeated move byte instruction (REP). In the case of MOVSB), one byte per iteration).

  If the check is complete and it is determined that a fast copy operation can be performed (based on the check and calculation of block 110), control passes from block 110 to block 130. At block 130, the head portion of the copy operation may be performed. Specifically, conditional read / store handling, for example, 64 bytes, and any length below a predetermined amount of data may be performed. As described herein, in one embodiment, a copy operation may be performed up to 8 times to copy data that is a maximum of 64 bytes. Specifically, if the check in block 110 is passed, the processor knows at this point that a copy operation longer than the native copy length can be performed without affecting the accuracy of the result.

  In block 130, the copy operation is using a "conditional" operation, and each of the N byte long conditional copies is performed if there is at least N bytes remaining. Since the condition is checked at runtime, it does not depend on propagation of length information returned from execution to the decoding stage. In addition to copying, at each iteration, the src and dst pointers to be used in the next operation are incremented by N and the remaining length is decremented by N.

  The number of copy operations can be completed in the "check" stage (block 110), set to propagate in the pipeline, and not penalized when in turn and used in the decode stage. To do. The time it takes for the “load zero overhead counter” or “zero overhead branch condition” to go from the decode stage to the final execution stage is the time frame during which the conditional operation is decoded and executed, and the pipe from decode to execution Equal to the depth of If the maximum read / store length (in bytes) that a machine can handle is “N = 2 ^ n”, it can be called a power-of-two sequence (a power of two trees). ), That is, 1, 1, 2, 4,..., N / 2, N, N, N can be used to perform the copy sequence. For example, assuming N = 16 and assuming the processor needs 8 operations to cover the pipeline delay, the sequence is 1, 1, 2, 4, 8, 16, 16, 16 and the maximum copy amount is 64B. For each number in the range 0 to 64B, there is a subset of operations that can move the same amount of data (eg, to move 3 bytes, perform 1 and 2 and 10 For bytes, perform 2 and 8.) As another example, assuming N = 32 and requiring 8 operations to cover the pipeline delay, the sequence is 1, 1, 2, 4, 8, 16, 32, 32. Yes, a total of 96B. In some embodiments, it is efficient that the maximum amount of data that the conditional part can handle is an integer multiple of the size of Fast Loop (eg, 64B × 1 = 64B, 64B × 2 = 128B).

  In one embodiment, the sequence of operations is performed in the opposite order as described above (eg, 16, 16, 16, 8, 4, 2, 1, 1), at the head portion of block 130, A subset of operations required to accurately copy any number of bytes of data in the range 0-64B can be easily generated. This sets a condition for checking the length of the remaining part, and if Reminder_Length (remaining length) -N> 0, the operation is completed, otherwise it is skipped. Reminder_Length is updated after each copy operation using its operation length. Instead of updating the src pointer and the dst pointer for each copy operation, it is also possible to update only the offset of the original src pointer and the original dst pointer, and the src pointer and the dst pointer are at the end of the block 130 ( (Or at another snapshot point in the block) updated to a new value. In this way, one “add” operation can be saved at each conditional stage.

  At the end of the head portion 130, a plurality of aspects are determined using the counter, the selected loop type, and the conditions provided in block 110. Specifically, when the zero overhead counter value is 1 or more, the counter is decremented by 1 and Fast Loop of block 140 is executed. If it is less than 1 and the tail condition is true (ie, the remaining number of bytes is less than 64 and greater than zero), the tail portion is executed at block 135. Otherwise, if additional data is not copied, method 100 ends. The zero overhead counter value is used to determine if “Fast Loop” needs to be called. The number of iterations (iterations) +1 is read into the counter, and when the counter value> 1, it is decremented and jumps to the head part of “Fast Loop”. When it is determined that the counter value is 1 or less, there is no need to call a loop.

  As shown in FIG. 1, if the remaining count value is greater than 63 bytes, control is transferred to block 140, eg, moving 64 bytes and / or cache line size data for each iteration. Fast fixed size iterations may be performed. This is a high-speed loop that handles a copy operation of a predetermined length with a pre-read zero overhead loop counter. In some embodiments, before performing the copy operation of block 140, a check is made as to when the hit is subject to a predictive miss penalty (however, "fast execution" is possible). First, a further pointer distance check is performed, which is necessary when the Fast Loop limit is more stringent than the conditional copy limit at the head portion. For example, a Fast Loop that does not track progress may need to be re-executed from the very beginning, in addition to all the checks previously performed, ((src mod 4K)-(dst mod 4K)) It is necessary to check> 63B. If the above check fails, control passes to block 160 and the second fast loop is executed (detailed below, but there is no limit but it is slow to execute) (2) the remaining length of the string is checked and if the length is greater than the specified threshold (NT_threshold), control passes to block 150 to avoid cache pollution. Loops using cache hints, such as non-temporal hints for read and store operations (eg, Intel® MOVNTDQA or MOVNTSQ instructions). In one embodiment, this NT_threshold parameter can be adjusted for the cache size to achieve the best performance impact. As another example implementation, multiple threshold levels may be used to determine the most appropriate use of the various caching hints.

  During each iteration of the loop of block 140, 64B of data is copied in the fastest possible manner (ie, a code sequence optimized for copy length is used). The number of iterations is determined using a zero overhead loop counter. At the end of the Fast Loop block 140, the condition for handling the tail is checked and the following decision is made (the condition is preset, so there is zero overhead). If the tail condition = true, control passes to the tail portion of block 135, otherwise, the method 100 ends without copying any further data.

  In block 160, fast_16 loop (fast 16 loop) is similar to Fast Loop, but copies 16B (depending on the sequence optimized for this copy length) at each iteration. The zero overhead counter is adjusted to allow for 16B iterations prior to execution of the loop.

  After copying as much of the 64B chunk (or the size of the copy operation of blocks 140, 150 and 160) as possible, a copy operation of 63B or less may remain (only if such a tail portion exists). , The processor reaches this state). The tail part is handled using the sequence of conditional copy operations in block 135, which is similar to the sequence used in the head part, except that the sequence is not two in one. No, 1 starts with 1 (1, 2, ...). The length of the tail portion is set to a size (for example, 63B = 64B-1) obtained by subtracting 1 from the data amount in one iteration of Fast Loop, and is not related to the depth of the pipeline. In the above example where N = 16 and Fast Loop is 64B, the tail portion is copied as a block of data of 16, 16, 16, 8, 4, 2, 1 bytes (7 operations). As described in the head section above, the reverse order is used to optimize the process of defining the subset of operations to be moved. When N = 32, the tail sequence is 32, 16, 8, 4, 2, 1 (6 operations).

  If the DF flag checked at block 110 is 1, the string is "reverse" and the source and destination pointers are decremented. In the algorithm described above, this case is handled by a native loop (control is transferred to block 120). As another example implementation, such a copy operation may be implemented using a similar “fast copy” sequence, using a symmetric scheme to invert the operation in the pointer adjustment operation.

  Although the implementation of the method 100 described above is for repeated copy operations using the REP MOVSB instruction, other implementations using other copy instructions may be employed. For example, an algorithm using a store instruction (for example, REP STOSB) can handle the same scheme as REP MOVSB, and load + store is used in the copy operation, but only store is executed in the store operation. Except as noted, the same steps as described above are used. In addition, in the case of REP STOSB, there are places where the process can be simplified. (1) There is no need to check the distance between src and dst. (2) There is no need to check the condition in the src pointer. In addition, a new step of preparing a storage data register having the length of the longest storage operation (N = 16 or N = 32 in the above example) is required, and the longest storage operation is for the storage action. (STOSB contains 1 byte of data that needs to be duplicated in each byte of the storage destination data register).

  The implementation example of FIG. 1 was an example adjusted to 64 bytes per REP MOVSB and one iteration, but other embodiments may be used to handle different lengths of high speed copy operations. Also, such an operation may be used to perform a fast copy operation using an instruction such as moving a double word length (eg, REP MOVSD) or other instructions. As another embodiment, the assumption that there is no “aliasing” of the page may be employed (in this case, module 4K is removed). As mentioned above, a portion of the code sequence is optimized to perform the desired operation in the most efficient manner for the particular type of instruction involved, and in another sequence portion, the same instruction May be performed in an unoptimized manner. In various embodiments, sequence detection techniques are implemented to analyze a sequence of incoming instructions and provide code to an execution unit to execute one or more instructions in a predetermined code sequence in an optimized manner. Make it possible.

  As an example, IA32 REP MOVS and REP STOS operations are tailored to handle copy operations whose length is not known in advance. The current optimization is based on using REP MOVSD to move most of the data and REP MOVSB for the rest, using 0-3 lengths for the rest. (Information used to optimize REP MOVSB execution time). An example of code that implements these copy operations is shown in Table 1 (similar structure applies to REP STOs).

  REP MOVSB is optimized by processing cases with length 0-3 early and penalizing other lengths. For the preceding operations, the above scheme is configured so that the count never exceeds 0-3. However, various other sequences may be used to perform such optimization, and in particular another sequence may be used to set the count of REP MOVSB instructions. When optimizing the behavior of REP MOVSB for lengths other than 0-3, for example when optimizing in relation to the remaining length of the REP MOVVSQ instruction being 0-7, the code It doesn't work well, and in many cases performance can be degraded (in the example, the length is 4-7). Similarly, other optimizations for REP MOVSB that would be efficient to handle any length, and quality degradation in the case of 0-3 lengths as part of such optimization If it does occur, the cords listed in Table 1 above will not work properly and performance will suffer. Even if the value of ecx can only be known at the time of instruction execution, it is necessary to determine at the time of instruction decoding what length REP MOVSB should handle in order to prevent time loss due to pipeline delay. , "Bubbles" that cause performance loss may be generated.

  In the optimization described above (Table 1), MOVSB follows immediately after the REP MOVSD instruction (referred to as the D + B sequence), which means that the programmer has a limited number of bytes, eg 0-3 bytes, of the REP MOVSB instruction. Serves as a hint that it is intended to be set to. Embodiments use this sequence hint to provide various instruction codes to the execution unit, allowing (at least) the second copy instruction to be optimized. Instead of searching for a specific sequence, the hardware follows the REP MOVSD instruction because the complete instruction sequence may vary and other code may be used to achieve the same result. Search for REP MOVSB with a small number of instructions (eg, 1-9). D + B sequences are not guaranteed to be detected regardless of which flow is decoded and which optimization is selected for a given data length, and even if decoding is performed correctly. It cannot be said that the sequence is not detected by mistake.

  FIG. 2 shows a block diagram of a sequence detector according to an embodiment of the present invention. As shown in FIG. 2, the processor 200 may include an instruction decoder 210 that receives instructions to be executed. When an instruction is received at the decoder, the received instruction may be stored in buffer 215. Buffer 215 may operate to provide decode logic 220 with the next instruction to be executed, which decode logic 220 receives a decode path selection signal from a feedback path that includes sequence detector state machine 240. Based on this selection signal and various rules of the decode logic 220, the instruction may be decoded and provided to the execution unit 230 for execution. Normally, the decode logic 220 receives an input instruction and generates a decoded instruction from the received instruction. In one embodiment, such decoded instructions may be in the form of machine code corresponding to the instructions and are provided to the execution unit 230 so that the instructions are executable. For example, the instruction code may cause the instruction unit to execute a microcode sequence or select a predetermined functional unit to perform a desired operation. The decode logic circuit may execute decoding of a plurality of instructions in parallel. For execution, another decode logic circuit may convert an instruction into multiple instructions.

  As shown in FIG. 2, the decoded instruction may be provided to the feedback path instruction comparator 225, and the decoded instruction may be compared to the predicted instruction code received from the state machine 240. The predicted instruction code may correspond to a predetermined instruction code that is desired to be optimized using the state machine 240 and decode logic 220 present in the first part of the code sequence. In some implementations, an implementation may use an index to an internal micro-operation array. Also, in some implementations, a plurality of such state machines and comparators may be arranged, each associated with a predetermined instruction to be searched for in the code sequence. In another implementation, the state machine 240 and the comparator 225 may be extended to support multiple instruction comparison and analysis.

  A match signal is reported from the comparator 225 to the state machine 240 if the two codes input to the comparator 225 match, as shown in the embodiment of FIG. The As shown in FIG. 2, the state machine 240 receives a stall signal (or information indicating instruction decoding) from the instruction decoder 210 every cycle. FIG. 2 shows a case where one instruction is decoded at a time, but the present invention can be extended when a plurality of instructions are decoded in parallel. The instruction decoder 210 holds an instruction supplied to the decode logic 220. In one embodiment, the decode logic 220 may include a logic function that parses the instruction using specific state information (eg, a mode of the machine that defines the instruction as illegal). The output of the decoder is shown as a “decoded instruction” and identifies the micro-operation that will be performed for this instruction. The nature of these operations depends on the machine's microarchitecture implementation, but can also be viewed as a binary value (or range of values) that uniquely represents the instruction. This code is provided to execution unit 230 so that the operation corresponding to the decoded instruction is executed in one or more cycles.

  In one implementation, optimization is loosely based on instruction sequences. It is assumed that the correct operation of the instruction is guaranteed regardless of the decision, so it is not necessary to guarantee that the sequence detection is accurate in all cases, and the detection of the sequence in most cases is detected Can be optimized. The instruction comparator 225 compares the current instruction from the state machine 240 with the “next instruction code” received from the instruction decoder 220. As described below, this code may cover a range of codes or one or more codes based on the state machine flow. If the comparison results match, the state machine 240 moves on to the next stage. The state machine moves from one stage to another based on detection of a match (the match may change from one state to another) or based on time or instruction decode count. If time is used, information indicating a stall is provided from the instruction decoder 210 and the state machine is stalled (eg, waiting for a fetch from the underlying cache or memory to complete). Or when the execution unit is busy and cannot execute a new instruction). Due to this stall, the count of execution cycles becomes an approximation of the count of decoded instructions, and this configuration may simplify the implementation. The sequence detector state machine 240 feeds back the status information signal to the decode logic 220 and is shown in FIG. 2 as a “decode path select signal”. This status information modifies the decode logic 220 so that for the same instruction in the instruction buffer 215, the decoder rules signal different decoded instructions to the execution unit 230.

  For clarity of operation, two cases are provided for the example of detecting and optimizing the execution of REP MOVSB. (1) If the REP MOVSB itself is used to copy what the data length is unknown and expected to be greater than 3 bytes (ie, a “long REP MOVSB” instruction), then the REP MOVSB When used in association with REP MOVSD in a sequence, the length for REP MOVSB instructions is expected to be in the range of 0-3 bytes, and will be referred to herein as "Short REP MOVSB". Two such different codes can be output from the instruction decoder 210, and the execution unit 230 executes a selected one of two different optimized copy operations.

  FIG. 3 is a state diagram of an example of a sequence decoder state machine according to one embodiment of the present invention, showing a state machine implementation. As shown in FIG. 3, in operation 310, the state machine is reset when searching for a REP MOVSD or REP STADOS instruction. In this case, the decode path selection signal from the state machine is set to generate a “long REP MOVSB” code if a REP MOVSB occurs during the code sequence. At the same time, the instruction decoder is supplied with the REP MOVSD and REP STOSD codes, and if one of the two codes occurs, information indicating that is provided to the sequence detection state machine and the REP MOVSB Alternatively, REP STOSB is switched to a mode that looks for “immediate follow” and a decode path selection signal is provided to encode the code for the “short REP MOVSB” operation. The state machine is in this state (operation 320--) during the specified REP MOVSB or REP STOSD threshold distance for a small number of "n non-stall cycles" or equivalent "nl instructions". 340). When one instruction is decoded at a time, nl is equal to n, and when a plurality of instructions are decoded simultaneously, nl is larger than n (for example, 4n). If a fetch stall or other stall occurs that prevents the decoder from issuing new instructions for this flow, the count is paused to ensure sequence detection. In this example, n is a small number, for example, 4. After such a delay, regardless of whether the REP MOVSB has arrived or not, the sequencer returns to the initial state 310 searching for REP MOVSD or REP STOSD, implying that a new REP MOVSD + B sequence has started. It will be. If no REP MOVSB is present or no REP STOSB is detected, the scenario covers that the code contains only REP MOVSD and elsewhere only REP MOVSB. In some embodiments, events such as interrupts occurring during state machine operations may be ignored, since the percentage of event occurrences is multiplied by the miss prediction penalty, so compared to the cost of the event. Because it becomes smaller.

  As an option, the state machine can be implemented to exit in state 320 or 330 and return to state 310 and search for REP MOVSB or REP STOSB without executing the last state, If the sequence is short (assuming that there is no REP MOVSD immediately following REP MOVSB and it is not detected during a fixed delay), there is no need to do this. In another embodiment, if the sequence distance between identified instructions is long, upon detection of the second (ie, another additional instruction), the state machine resets to the first search state (state 310). May be.

  The fact that complete execution is guaranteed regardless of the optimization chosen also covers cases like exceptions between the REP MOVSD and REP MOVSB instructions. If such a rare condition occurs, REP MOVSB execution may choose a non-optimal path, which may incur a cost in terms of performance, but impairs the correct execution of the code You might be able to avoid that. There are other cases that cause misprediction such as pipeline sweeping (eg, REP MOVSB is decoded after REP MOVSD and swept out). In such a case, it is usually desirable not to reset the state machine, which would cause the REP MOVSB to be decoded again with high probability within the allowed delay time frame.

  In one embodiment, the sequence detector state machine implementation may be relaxed to correctly handle the case where the flow is not perfect and fluctuates. For example, instead of searching for a complete sequence, this problem can be addressed by using a timer.

  Current decoders can decode multiple instructions at once. The implementation described above can be extended in several ways to include this case. Initially, it is possible to limit the decoding of instructions to be searched to one at a time. In the REP MOVSB example, the REP MOVSD and REP STOSD instructions are decoded by themselves. Next, multiple compare operations are performed on the output of each decoder to serialize (flush more recent operations) or use multiple comparators for all of the predicted codes. The state machine can follow the code sequence from any operation. If non-serialized decoding is used, the state machine may be extended to support multiple stage branches simultaneously (such as supporting a second match decoding in parallel with the first decoding). .

  Embodiments allow optimization of the REP MOVSB instruction, which provides significant benefits for new code without incurring performance loss for current code optimized to use the REP MOVSD + B sequence.

  FIG. 4 shows a block diagram of a processor according to an embodiment of the present invention. As shown in FIG. 4, the processor 400 may be an out-of-order processor pipelined in multiple stages. In FIG. 4, the processor 400 is depicted in a relatively simplified manner to illustrate various features used in connection with the instruction coordination described above.

  As shown in FIG. 4, the processor 400 includes a front end unit 410 that is used to fetch macroinstructions to be executed and prepares these microinstructions for later use in the processor. For example, the front end unit 410 may include a fetch unit 404, an instruction cache 406 and an instruction decoder 408. In some implementations, the front-end unit 410 may further include a trace cache along with microcode storage and micro-op (μOP) storage. The fetch unit 404 may fetch the macro instruction from, for example, a memory or instruction cache 406 and provide it to the instruction decoder 408 to decode the instruction into a basic instruction, ie, a μOP executed by the processor. In one embodiment of the present invention, sequence detection is performed so that an input instruction group includes a predetermined sequence of two or more instructions (or, as described above, selected instruction sequences are close to each other). An instruction decoder 408 is configured to include logic to execute. This logic causes the instruction decoder 408 to provide various decoded instructions, eg, μOPs that are later executed in the processor pipeline, to optimize performance. In some implementations, when a predetermined macroinstruction is received, the instruction decoder 408 causes a predetermined microcode sequence to be transmitted for execution, which is a high speed according to an embodiment of the present invention. Mode copy operations may be handled. In another implementation, the execution unit may be extended to specific hardware to perform fast copy operations efficiently in response to decoded instructions.

  Connected between front end unit 410 and execution unit 420 is an out-of-order (OOO) engine 415 that may be used to receive micro-instructions and prepare for execution. Specifically, the OOO engine 415 may include various buffers for reordering the microinstruction flow and allocating various resources necessary for execution. It also provides logical register renaming for storage locations in various register files, such as register file 430 and extended register file 435. Register file 430 may include separate register files for integer and floating point operations. The expanded register file 435 may provide a storage area such as a unit of vector size, for example, 256 bits or 512 bits per register.

  Various resources may exist within execution unit 420, including, for example, various integers, floating point and single instruction multiple data (SIMD) logic units, and other dedicated hardware. The result is provided to retirement logic, ie, a reorder buffer (ROB) 440. Specifically, ROB 440 may include various arrays and logic that receive information associated with instructions to be executed. The information is examined by the ROB 440 to determine if the instruction can be retired effectively and determine if the resulting data is committed to the processor's architectural state, or prevent proper retirement of the instruction Determine whether the error occurred. Of course, ROB 440 may handle other operations for retirement.

  As shown in FIG. 4, ROB 440 is connected to cache 450 and the present invention is not limited in this regard, but in one embodiment may be a low tier cache (eg, an L1 cache). The execution unit 420 can be directly connected to the cache 450. Communication from the cache 450 to a higher hierarchy cache, system memory, etc. may occur. In the embodiment of FIG. 4, this configuration is shown in a higher hierarchy, but the present invention is not limited in this respect.

  Embodiments may be implemented in many different system types. FIG. 5 shows a block diagram of a system according to an embodiment of the present invention. As shown in FIG. 5, the multiprocessor system 500 is a point-to-point interconnect system that includes a first processor 570 and a second processor 580 that are coupled by a point-to-point interconnect 550. As shown in FIG. 5, each of the processor 570 and the processor 580 is a multi-core processor, and includes a first processor core and a second processor core (ie, processor cores 574a and 574b and processor cores 584a and 584b). Each processor core may include hardware, software, and firmware that performs instruction coordination, as shown in FIGS. 1-4.

  As shown in FIG. 5, the first processor 570 includes a memory control hub (MCH) 572 and point-to-point (PP) interfaces 576 and 578. Similarly, the second processor 580 includes an MCH 582 and PP interfaces 586 and 588. As shown in FIG. 5, MCH 572 and MCH 582 connect processors to their respective memories, ie, memory 532 and memory 534, which are main memories (eg, dynamic memory) that are locally attached to the corresponding processor. It may be part of a random access memory (DRAM). The first processor 570 and the second processor 580 may be coupled to the chipset 590 via PP interconnections 552 and 554, respectively. As shown in FIG. 5, the chipset 590 includes PP interfaces 594 and 598.

  Chipset 590 also includes an interface 592 that connects chipset 590 to high performance graphics engine 538. Similarly, the chipset 590 may be connected to the first bus 516 via the interface 596. As shown in FIG. 5, various I / O devices 514 may be connected to the first bus 516, and the bus bridge 518 connecting the first bus 516 and the second bus 520 is the first bus. 516 may be connected. Various devices may be connected to the second bus 520, such as a keyboard / mouse 522, a communication device 526, and other mass data storage devices that may include a disk drive or code 530 in one embodiment. A storage unit 528 may be connected. Further, the audio I / O 524 may be connected to the second bus 520.

  Embodiments may be implemented in code or stored on a storage medium that stores instructions that can be used to program the system to execute instructions. Storage media include, but are not limited to, any disks including floppy disks, optical disks, compact disk read only memory (CD-ROM), rewritable compact disks (CD-RW) and magneto-optical disks. And random access memory (RAM) such as read only memory (ROM), dynamic random access memory (DRAM) and static random access memory (SRAM), erasable-programmable read only memory (EPROM), flash memory, Electrically erasable—Includes programmable read only memory (EEPROM), semiconductor devices such as magnetic or optical cards, or other types of media suitable for storing electrical instructions.

Although the present invention has been described with reference to a limited number of embodiments, it will be apparent to those skilled in the art that many variations and modifications are possible. Such variations and modifications are intended to be included within the scope of the appended claims within the scope and spirit of the present invention. Examples of embodiments of the present invention are shown as items below.
[Item 1]
An execution unit that performs the operation indicated by the instruction code;
An instruction decoder for receiving an input instruction;
With
The instruction decoder includes first logic for receiving a first input instruction and receiving a path selection signal from the feedback path;
The feedback path is coupled to the instruction decoder and includes a sequence detector coupled to the instruction decoder to generate a path selection signal;
The path selection signal corresponds to the detection of different input commands received by the command decoder within the threshold distance of the first input command,
The first logic is a device that decodes a first input instruction into a first instruction code or a second instruction code in response to a path selection signal.
[Item 2]
The apparatus according to item 1, further comprising a comparator that receives an instruction code from the instruction decoder and a prediction code from the sequence detector and generates a match signal when the instruction code and the prediction code match.
[Item 3]
The sequence detector generates a first state path selection signal that causes the first logic to decode the first input instruction into a first instruction code when the coincidence signal is not generated. Item 3. The device according to item 2, which corresponds to a copy operation optimized for the data length.
[Item 4]
The sequence detector is responsive to the match signal to generate a second state path selection signal that causes the first logic to decode the first input instruction into a second instruction code, the second instruction code having a first data length and The apparatus according to item 3, which corresponds to a copy operation optimized for a different second data length.
[Item 5]
The apparatus according to item 4, wherein the second instruction code causes the execution unit to execute a copy operation having a finite length.
[Item 6]
Item 4 for generating a second state path selection signal when a different input command is received by the command decoder within a first number of commands corresponding to a threshold distance from the first input command. The device described in 1.
[Item 7]
The apparatus according to item 6, wherein the threshold distance is approximated by the cycle number and decode stall information.
[Item 8]
7. The apparatus of item 6, wherein the sequence detector has a state machine and the state machine is reset if a different input command is not received within the first number of commands.
[Item 9]
Determining whether the iterative copy instruction can be optimized based at least in part on information associated with the iterative copy instruction;
If it is determined that it is possible, using a power-of-two copy of the tree, the first quantity or less of data is sent from the first source location to the first copy in the first quantity or less. Executing a first portion of the iterative copy instruction with a first sequence of conditional copy operations to copy to a destination location;
If the remaining portion of the data to be copied is greater than the first threshold, use a fast loop of copy operations to copy a second amount of data from the second source location to the second destination location. Performing a second part of the iterative copy instruction;
If there is still data to be copied thereafter, a condition for copying the data of the third amount or less in the number of chunks of the third number or less from the third copy source location to the third copy destination location. Performing a third part of the iterative copy instruction by a second sequence of append copy operations;
A method comprising:
[Item 10]
10. The method of item 9, further comprising obtaining setup information for a fast loop and a second sequence of conditional copy operations prior to performing the first sequence of conditional copy operations.
[Item 11]
Determine whether the second amount of data is greater than the second threshold and, if so, copy the second amount of data directly to memory using caching hints without storing it in the cache The method according to item 9, further comprising the step of:
[Item 12]
The first of the first sequence of conditional copy operations copies an N-byte data chunk, increments the first and second pointers associated with the first sequence of conditional copy operations, and the remaining to be copied 10. The method according to item 9, wherein the counter associated with the data is updated.
[Item 13]
The power of the tree of 2 starts with the first length of the power of 2 corresponding to the maximum read length or the maximum storage length of the processor, and ends with the last length of the power of 2 corresponding to 1 byte. The method described in 1.
[Item 14]
Determining whether the difference between the first pointer and the second pointer associated with the iterative copy instruction is between a third threshold and a fourth threshold;
10. The method of item 9, wherein if the result of the determination is true, a second amount of data is copied using a copy operation having a width shorter than one iteration of the fast loop.
[Item 15]
A processor having a front end including a decoder;
A system comprising a dynamic random access memory (DRAM) coupled to a processor,
The decoder includes first decoding logic;
If the decoder including the input copy instruction and at least one other copy instruction indicates that a sequence of instructions has been received, the first decoding logic receives the input copy instruction and provides feedback coupled to the decoder. Receiving a selection signal from the second logic in the path, and in response to the selection signal, decoding the input copy instruction into a first instruction code or a second instruction code;
The system further comprises an execution unit that receives the first instruction code or the second instruction code and executes the first copy operation or the second copy operation in response to the received instruction code, respectively.
[Item 16]
The second logic includes a sequence detector;
If an input copy instruction is received in the first number of instructions after a second input copy instruction corresponding to at least one other copy instruction, causes the decode logic to generate a second instruction; otherwise 16. The system according to item 15, wherein a selection signal for causing the decoding logic to generate the first instruction is generated by the sequence detector.
[Item 17]
17. The system of item 16, wherein if the input copy command is not received within the first number of commands, the sequence detector is reset to a first state that searches for a second input copy command.
[Item 18]
18. The system of item 17, wherein the sequence detector proceeds from a first state to a second state that searches for an input copy command after a second input copy command is detected.
[Item 19]
The system of item 16, further comprising a comparator that receives the instruction code from the decoder and the prediction code from the sequence detector and generates a match signal if the instruction code and the prediction code match.
[Item 20]
16. The system of item 15, wherein the first copy operation is optimized for a first data length and the second copy operation is optimized for a second data length different from the first data length.

Claims (14)

An execution unit that performs the operation indicated by the instruction code;
An instruction decoder for receiving an input instruction ;
A sequence detector connected to the instruction decoder and generating a path selection signal ;
The instruction decoder receives the instruction includes a first logic to receive the route selection signal from the sequence detector,
The route selection signal is for a predetermined input command is a second type of copy command indicating whether it is within the range of threshold distance since the received to the first logic,
Wherein the first logic is, upon receiving a first input command is a first type of copy command, based on the path selection signal, the first input instruction, the first instruction code or the second instruction code The device that is to be decoded into. A comparator that receives an instruction code from the instruction decoder and a prediction code from the sequence detector, and generates a match signal when the instruction code and the prediction code match , wherein the prediction code is: The apparatus of claim 1, further comprising the comparator being an instruction code corresponding to the second type of copy instruction . The sequence detector outputs the first input command to the first logic when the match signal is not generated or when the threshold distance is exceeded after the match signal is generated . Generating the route selection signal in a first state to be decoded into an instruction code ;
Wherein the first instruction code corresponds to an optimized copy operation for the first data length, according to claim 2. A second state in which the sequence detector causes the first logic to decode the first input instruction into the second instruction code in response to being within the threshold distance after the coincidence signal is generated; Generating the route selection signal of
The second instruction code, wherein the first data length corresponds to a copy operation which is optimized for a different second data lengths, according to claim 3. The second instruction code, the execution unit is intended to perform the finite length of the copy operation, according to claim 4. The sequence detector generates the path selection signal in the second state when the predetermined input command is within a first number of commands corresponding to the threshold distance after being received by the first logic. it is to apparatus of claim 4. Said threshold distance and to be compared, the predetermined input command and subsequent length of the first input instruction preceding are those obtained by the number of cycles and the decode stall information device according to claim 6. The sequence detector has a state machine;
If the first input command is not received by the first logic within the first number of commands since the predetermined input command was received by the first logic, the state machine is reset. The apparatus of claim 6, wherein A processor having a front end including a decoder;
A dynamic random access memory (DRAM) coupled to the processor,
The processor includes second logic connected to the decoder to generate a selection signal;
The decoder includes first decoding logic for receiving an instruction and receiving the selection signal from the second logic ;
The selection signal includes a first instruction received following the predetermined copy instruction in response to a predetermined copy instruction being a second type of copy instruction being received by the first decoding logic . If the input copy instruction is a copy instruction of the type, it is suggested that a sequence of instructions including the predetermined copy instruction and the input copy instruction is received by the first decoding logic,
It said first decoding logic, when receiving the input copy command is a predetermined first type of copy command, based on the selection signal, the input copy command, the first instruction code or is intended to decode to the second instruction code,
Wherein the processor, the first instruction code or receives the second instruction code, in response to a command code received, or the first copy operation further comprising an execution unit for executing the second copy operation, respectively, the system . The second logic includes a sequence detector;
The sequence detector generates the selection signal;
The selection signal is sent to the first decoding logic when the input copy instruction is received in a first number of instructions after a second input copy instruction corresponding to the predetermined copy instruction. to generate an instruction code, the otherwise, it is intended to generate the first instruction code to said first decoding logic, according to claim 9 system. The input copy command, wherein when the first not received by the number in the instruction, the sequence detector is reset to the first state of searching for the second input copy command, according to claim 10 System. 12. The system of claim 11 , wherein the sequence detector proceeds from the first state to a second state that searches for the input copy instruction after the second input copy instruction is detected. A comparator that receives an instruction code from the decoder and a prediction code from the sequence detector and generates a match signal when the instruction code and the prediction code match , the prediction code being the first code The system of claim 10 , further comprising the comparator being an instruction code corresponding to two types of copy instructions . Wherein the first copy operation is optimized with respect to the first data length, the second copy operation, according to claim 9, which is optimized for a different second data length from the first data length System.

Images