Reducing overhead in processor array search

Abstract

A processor (100) including an instruction storage (114) configured to store processor instructions, a data storage (120) configured to store processor data representing an array including a plurality of data elements, a controller (102), and an instruction pipeline (104). The instruction pipeline includes a load stage circuit (126) configured to load the array elements from the data storage, a compare stage circuit (128) configured to compare the array elements with a reference value, a store stage circuit (130) configured to store a result set including results of the comparison of the array elements with the reference value, and a loop hit detection stage circuit (132) configured to determine whether any of the result set is associated with a hit against the reference value.

Description

[Background technology]

[0001] The described examples relate to electronic processors, and more particularly to improving hardware or processor performance, for example, reducing overhead in processor array searches.

[0002] Computational programming and processing often require searching for values ​​in an array, typically by comparing a predetermined value to each element in the array. When a search match (hit) occurs, the location (index) of the matching array element is often returned or stored for subsequent action. Alternatively, the search may be completed by simply identifying that the element being searched for is located somewhere in the array. Searches can be performed in a variety of forms, examples of which include linear (sequential) searches and interval (e.g., binary) searches. Data array value searches can be used in many applications, including, for example, numerical data processing and image / audio processing.

[0003] A processor architecture may be programmed using a high-level language to search for an element in an array, with the programming compiled into some low-level instructions (object code) that are processed by machine-level instructions through a processor pipeline. Generally, the low-level instructions include three functions: (1) first, load one or more instructions and operands. These operands include the search value and the array element; (2) second, execute the instruction to compare the search value with the array element; and (3) in response to the search result, if a comparison mismatch (a miss) occurs, branch control causes the flow to loop and repeat these three functions for the next array element. On the other hand, if a comparison match (a hit) occurs, branch control causes the search sequence, and any looping, to terminate, completing the search and performing the next action. Therefore, when a miss occurs and a branch requires repeating or looping these same steps, the resulting resource penalty may be referred to as loop overhead, which may include looping until the search is complete. Additionally, in many modern processors (such as reduced instruction set computers and their variations), the processor includes a pipeline design with multiple stages, often involving instruction fetch, operand read, execution, and writeback. As successive instructions pass through the pipeline, the efficiency of processing later instructions in a sequence often depends on the processing of earlier instructions in the sequence, including stalls, pipeline flushes, branch prediction, and other management of pipeline artifacts. Pipeline depth, which refers to the number of stages, incurs pipeline overhead. Thus, array searches can be resource-intensive in terms of both loop overhead and pipeline overhead. This specification provides examples that may improve upon various of the above considerations, as well as other concepts, and are discussed in more detail below. Summary of the Invention

[0004] In one example, there is a processor including an instruction storage configured to store processor instructions, a data storage configured to store processor data representing an array including a plurality of data elements, a controller, and an instruction pipeline including a load stage circuit configured to load the array elements from the data storage, a comparison stage circuit configured to compare the array elements with a reference value, a store stage circuit configured to store a result set including results of the comparison of the array elements with the reference value, and a loop hit detection stage circuit configured to determine whether any of the result set is associated with a hit against the reference value.

[0005] Other aspects are also disclosed and claimed. [Brief explanation of the drawings]

[0006] [Figure 1] FIG. 2 is a block diagram of a processor.

[0007] [Figure 2] 2 illustrates instruction progression implemented by object code in the processor of FIG. 1;

[0008] [Figure 3A] 2 illustrates an example of an array search using the instruction progression of FIG. 2 in searching for an array value 30. [Figure 3B] 2 illustrates an example of an array search using the instruction progression of FIG. 2 in searching for an array value 30. [Figure 3C] 2 illustrates an example of an array search using the instruction progression of FIG. 2 in searching for an array value 30.

[0009] [Figure 4] 3 illustrates the expansion of the instruction progression of FIG. 2 in a larger array and concurrent instructions over a larger number of clock cycles.

[0010] [Figure 5]A search example using the instruction progression 400 of FIG. 4 is illustrated in a search for an array value 30.

[0011] [Figure 6] Illustrates instruction progression with additional parallelism by operating on two different array elements simultaneously.

[0012] [Figure 7] An example of an array search using the instruction progression of FIG. 6 is illustrated in the search for array value 30.

[0013] [Figure 8] Illustrates instruction progression using instructions that target four different array elements simultaneously.

[0014] [Figure 9] A search example using the command progression of FIG. 8 is illustrated in the search for array value 30.

[0015] [Figure 10] 1 is a flow chart of an exemplary sequence searching method. DETAILED DESCRIPTION OF THE INVENTION

[0016] FIG. 1 is an exemplary block diagram of a processor 100 including a structure and operable to perform an array search. The processor 100 may take various forms, such as a general-purpose microprocessor, an application-specific processor, a digital signal processor, or a microcontroller. The processor 100 includes a controller 102, which may be coupled to control various other blocks of the processor 100, including at least one instruction pipeline 104. The instruction pipeline 104 represents control logic that manages the operational flow and interaction with the various operational blocks and includes several different stages, logically characterized by the functionality associated with each stage as an instruction is processed through the respective stage. Each of these stages has some form of physical circuit representation, e.g., control logic for implementing the stage functionality, and may be used alone or in conjunction with other illustrated blocks (or understood blocks not otherwise shown). By way of example, these stages may include several specialized integrated circuits, including an instruction fetch stage 106, an instruction decode stage 108, an operand fetch stage 110, and an execution stage 112. Conceptually, these stages are generally sequential, each occurring in a separate clock cycle (or cycles), and the functionality occurs either in the hardware for that stage or in combination with other blocks in processor 100. However, the functionality / timing of one stage may overlap with another, and each stage may be further subdivided physically or operationally in different architectures and different processor models. Thus, the description of instruction pipeline 104 in general is not intended to be limiting, and the concepts described and claimed herein may be implemented in a variety of pipelined processors.

[0017] The instruction fetch stage 106 is coupled to an instruction buffer 114 and fetches one or more instructions at a time from the instruction buffer 114. The instruction buffer 114 is coupled to a system bus 116 and temporarily stores instructions received from the system bus 116. The system bus 116 is coupled to various blocks, including a system memory 118, from which instructions are transferred to the system bus 116. The system memory 118 may include one or more levels of cache memory. The transfer of instructions from the system memory 118 to the instruction buffer 114 via the system bus 116 may occur under the operation of the controller 102, which may include dedicated structures for handling such instruction transfers, such as a direct memory access (DMA) controller. Thus, through these various structures and paths, the system memory 118 serves as a processor- (or computer-) readable storage medium on which instructions may be stored and then read for execution by the processor 100. Each fetched instruction is in a format compatible with the specifications of the processor 100 and may represent, for example, an object code-level instruction resulting from compiling high-level language programming instructions. In one example, the code may be provided directly to the processor 100 in object code form (and may be compiled anywhere else, such as on a general-purpose computer). In the context of this example, the high-level language programming instructions include one or more array search instructions intended to search an array to determine whether a reference value matches any element in the array, and, optionally, to identify the location (index) within the array at which the match is identified, if there is a match. Thus, unless otherwise noted, the level instructions described below should be understood to be object code instructions obtained by compiling such high-level array search instructions.

[0018] The instruction decode stage 108 receives one or more instructions at a time and then decodes them according to the binary state and position of each instruction's bits. Generally, an instruction may include one or more fields, such as an instruction opcode, that indicate the function of the instruction, and one or more operands that indicate the location of something that is either directly performed or acted upon by the operation of the instruction. Multiple instructions may be decoded at one time. For example, a very long instruction word (VLIW) architecture may include some form of instruction parallelism, where multiple instructions may be processed by one or more stages of the pipeline 104, including the instruction decode stage 108. A VLIW may be formatted, for example, as one large instruction or as a fixed instruction packet. In any event, a program may explicitly provide multiple instructions at the same time, where instructions may be decoded and subsequent processes may occur simultaneously, as long as there are no dependencies between the instructions that prevent one or more instructions from being executed concurrently or otherwise out of order.

[0019] Operand fetch stage 110 is controlled based on the instruction function identified by instruction decode stage 108 to retrieve one or more values ​​for use in subsequent execution of the respective instruction. Retrieving such values ​​is known as fetching from a register or data memory element. The fetched values ​​may represent data, such as one or more data elements in an array to be searched. Typically, the retrieved values ​​are from nearby high-speed data storage, such as a block of registers 120. Registers 120 may also be coupled to system bus 116, via which values ​​may be provided between registers 120 and system memory 118. Thus, the fetched values ​​may be immediate register values ​​in registers 120, e.g., already available in the registers from execution of a previous instruction, or may be transferred from a storage location in system memory 118. Additionally, to the extent processor 100 supports parallelism, operand fetch stage 110 may simultaneously fetch multiple values, e.g., corresponding to multiple instructions being executed.

[0020] Execution stage 112 executes instructions and, to the extent instruction execution provides a data result, the result is written to an appropriate target destination, such as in registers 120 or to write buffer 122. Write buffer 122 is also coupled to system bus 116. Execution by execution stage 112 is typically implemented with not just the stage's control logic but also additional circuitry, such as dedicated functional units 124, operable to perform certain operations on a unit basis (e.g., integer operations, floating-point operations, video processing, etc.). As will be described below, in this example, execution stage 112 also includes additional structures and / or functionality that execute to provide and complete concurrent operations for the array search function, including a LOAD_EX stage 126 for loading array elements, a COMPARE_EX stage 128 for comparing the loaded array elements to a reference value, a STORE_COMP_HIS_EX stage 130 for storing / aggregating a history of each comparison as the array is processed, and a LOOP DECISION_EX stage 132 for periodically reviewing the history and determining subsequent actions from the history, such as whether to continue or terminate the search function. The stored history and the results of the periodic review may be represented in registers of registers 120; for illustrative purposes, an additional loop processing register 134 is shown as part of registers 120. Of course, execution stage 112 and functional units 124 may include and provide a variety of other structures and functionality, such as those associated with conventional or upcoming processor architectures. In either event, once the execution stage 112 executes each instruction to some result, that result may be represented by a value written to the write buffer 122, from which it may be further read or transferred to some other destination, for example via the system bus 116.

[0021] Processor 100 may also include other structures and functionality. For example, FIG. 1 includes certain such items, including an input / output (I / O) block 136 and peripherals 138. I / O block 136 may couple to system bus 116 and provide an interface (not explicitly shown) to other devices external to processor 100 to facilitate communication between I / O block 136 (and system bus 116) and such devices. Peripherals 138 may take various forms known in the art. Other structures and functionality, such as those already existing or developed in the art, may also be included but are not shown for simplicity. For example, in a secure processor architecture, additional safety and / or security structures may be included between system bus 116 and a physical layer interface. The physical layer interface may be an interface between I / O block 136 to external connections, as well as to system memory 118 and peripherals 138. Still other structures are contemplated and will be ascertainable by those skilled in the art.

[0022] For example, consider the high-level programming pseudocode in Table 1 below. TIFF2025533021000002.tif56150 Generally, the pseudocode in Table 1 is intended to illustrate an example loop that compares a reference value REF to each value in an array ARRAY, which has a total of N+1 elements. The comparison illustrated by the pseudocode and performed by the corresponding object code in processor 100 conditionally loops through index [i] from [i=0] up to [i=N]. This comparison is controlled by initialization in INS0 and various conditional instructions, with the index incremented by INS3. Thus, the collective code compares ARRAY values ​​at one index [i] at a time until a comparison hit is found. If a comparison hit is found, the index [i] from the hit is stored and a flag HIT_FLAG is set. Alternatively, each time a comparison miss occurs, the loop evaluates the next ARRAY value at the incremented index [i] until each element in the entire ARRAY has been compared to REF.

[0023] In some alternative architectures, the pseudocode of Table 1 typically requires N clock cycles per loop iteration until a hit is found. Each such iteration includes at least a load, a comparison, and then a branch decision based on the result of the comparison, so N represents the total number of clock cycles to accomplish these steps for a given iteration. Generally, each miss causes a branch decision to cause the loop to repeat, resulting in N clock cycles. Thus, for a given array search, if a total of M misses occur, resulting in a loop, it will take at least M×N clock cycles to complete the array search. In other words, because loop overhead inherently grows with each miss, the loop overhead penalty can be significant when searching a relatively large number of elements. In contrast, processor 100 implements structure and functionality to significantly reduce such overhead, as described in more detail below.

[0024] FIG. 2 illustrates an instruction progression 200 implemented by object code in the processor 100 of FIG. 1 to achieve functionality corresponding to the pseudocode in Table 1. The illustration in FIG. 2 provides a first example and also serves as a simplified introduction to additional examples provided later. In contrast to the examples provided later, in FIG. 2, the LOAD_EX stage 126 of the execution stage 112 supports a single comparison operation per clock cycle, while other portions of the execution stage 112 can perform other functions simultaneously with this comparison. In FIG. 2, the vertical axis indicates successive clock cycles (downward), and the illustrated process spans a total of six clock cycles, numbered 0 through 5. The horizontal axis of FIG. 2 also indicates the sequence to which a particular execution instruction belongs. In the first example, the first row of FIG. 2 indicates clock cycle 0, during which only a single instruction, LOAD A[0], from instruction sequence 0 is executed by the LOAD_EX stage 126 to load the first array element into a register. In the second example, the second row of FIG. 2 indicates clock cycle 1, during which two instructions are executed. That is, for instruction sequence 0, COMPARE A[0],REF is executed by COMPARE_EX stage 128 to compare the register value loaded in clock cycle 0 with a reference value REF, which may be pre-stored in a separate register. Meanwhile, in the same clock cycle 1, for instruction sequence 1, an additional load, shown as LOAD A[1], is executed by LOAD_EX stage 126 to load the next ARRAY element into a register. The load instruction may have been initiated earlier in instruction pipeline 104, for example as part of operand fetch stage 110, but is completed in LOAD_EX stage 126, separate from other stages such as COMPARE_EX stage 128. Thus, during clock cycle 1, portions of two different instruction sequences 0 and 1 are executing simultaneously, one in LOAD_EX stage 126 and the other in COMPARE_EX stage 128. The remaining examples will be further understood below.

[0025] 2 compares three array elements to REF over a total of four clock cycles (0, 1, ..., 3), but for each instruction sequence (0, 1, 2), an additional object code instruction is executed after the comparison to store the history associated with the comparison result. This additional instruction is identified herein as STORE_COMP_HIS and is executed by STORE_COMP_HIS_EX stage 130. In this example and other examples described below, the history stores a hit / miss indicator of the comparison result. The hit / miss indicator may be stored in a temporary or dedicated storage location, such as the one-bit HIS_FLAG register or a value that is part of a larger quantity of bits, which may be part of loop processing registers 134 of FIG. 1. For example, in clock cycle 2, STORE_COMP_HIS stores the hit / miss indicator for instruction sequence 0, i.e., COMPARE A[0],REF, in the immediately preceding clock cycle 1. Similarly, in clock cycle 3, STORE_COMP_HIS stores the hit / miss indicator for COMPARE A[1],REF of instruction sequence 1 in the immediately preceding clock cycle 2. Finally, in clock cycle 4, STORE_COMP_HIS stores the hit / miss indicator for COMPARE A[2],REF of instruction sequence 2 in the immediately preceding clock cycle 3. Thus, multiple instances of STORE_COMP_HIS store and provide an aggregated history of successive comparisons, each associated with a different array element, facilitating additional functionality described below.

[0026] The instruction progression 200 of FIG. 2 also shows that in clock cycle 5, following several instruction sequences, in this example three such sequences (0, 1, 2), an additional LOOP DECISION instruction is executed by the LOOP DECISION_EX stage 132 on the data loaded and compared in the preceding group of comparisons. In this example, the LOOP DECISION instruction processes the aggregated history information of sequences 0 through 2 (from multiple previous executions of STORE_COMP_HIS) to determine whether a comparison hit occurred and, if so, at which array index location the hit occurred. The hit location index may be stored in a temporary or dedicated storage location, such as a HIT_INDEX register, which may also be part of the loop processing registers 134. If no such hit occurs, and as shown in additional examples below, the LOOP DECISION may indicate that additional array elements may be processed. In contrast, if a hit occurs, the loop may terminate and branch to some other instruction related to a function other than array searching. Thus, as further shown below, aggregating loop history (STORE_COMP_HIS) and processing that history (LOOP DECISION) can significantly reduce loop overhead during array searches compared to prior art techniques.

[0027] 3A-3C illustrate example array searches 300_A, 300_B, and 300_C, respectively, using the instruction progression 200 of FIG. 2. Each of these figures illustrates the first three ARRAY elements (elements indexed as [0], [1], and [2]), along with the stored values ​​and an example criteria search for REF=30. Generally, in FIG. 3A, a hit (i.e., the location of the value 30) occurs at A[2], in FIG. 3B, a hit occurs at A[1], and in FIG. 3C, there is no hit. Additional details below cover the aggregated loop history and its processing.

[0028] For the example values ​​in FIG. 3A , according to the progression of FIG. 2 , in clock cycle 0, A[0]=16 is loaded into the register, in clock cycle 1, the register value is compared with REF=30 to generate a miss, and in clock cycle 2, the respective miss history is stored by HIS_FLAG. For example, HIS_FLAG=0 indicates a miss. Partially overlapping with the above, in clock cycle 1, A[1]=62 is loaded into the register, in clock cycle 2, the register value is compared with REF=30 to generate a miss, and in clock cycle 3, the respective miss history is stored by HIS_FLAG=0. Also partially overlapping with the above, in clock cycle 2, A[2]=30 is loaded into the register, in clock cycle 3, the register value is compared with REF=30 to generate a hit, and in clock cycle 4, the respective hit history is stored, for example, HIS_FLAG=1 indicates a hit (here, of course, complementary miss / hit values ​​could be used as 1-bit values ​​for HIS_FLAG). In clock cycle 5, when LOOP DECISION executes, the stored HIS_FLAG is processed to identify the HIT_INDEX location of the hit (at [2]). In one example, this identification can be implemented as a count. The count starts at count 0 with the earliest HIS_FLAG in time, increments for each cleared flag thereafter, and stops incrementing when a hit (HIS_FLAG=1) is encountered. Note that the HIT_INDEX value is considered valid only if a hit occurs. Prior to that point, it is essentially an increment of the count of a miss, rather than an identification of where the hit occurred. In FIG. 3A, for example, from clock cycle 2, the count equals 0 for HIS_FLAG=0, increments to a count of 1 for HIS_FLAG=0 from clock cycle 3, and stops incrementing at the then-valid count of 2 for HIS_FLAG=1 in clock cycle 4. This means that at that point HIT_INDEX=2 will correspondingly identify array element A[2] as the location where the comparison hit occurred.Also, such a count may be implemented by dedicated hardware or by a progressing (e.g., incrementing) value in a storage location, either of which may be contained in loop processing register 134. Thus, by the completion of clock cycle 5, LOOP DECISION will have determined that a hit occurred and the index [i=2] for that hit, after which the array search is complete. Also, note that this count can process multiple HIS_FLAGs in a single clock cycle and, therefore, can increment by a value greater than just 1 in a single clock cycle. For example, in FIG. 3A, the count evaluates three such flags (corresponding to A[0], A[1], and A[2]) and can increment from 0 to 2 in a single clock cycle. Additional examples using other potential increment values ​​in a single cycle are provided below.

[0029] 3B, again in clock cycle 0, A[0]=16 is loaded into a register, in clock cycle 1 the register value is compared with REF=30 to generate a miss, and in clock cycle 2 the respective miss history is stored with HIS_FLAG=0. Partially overlapping with the above, but in clock cycle 1, A[1]=30 is loaded into a register, in clock cycle 2 the register value is compared with REF=30 to generate a hit, and in clock cycle 3 the respective hit history is stored with HIS_FLAG=1. Also partially overlapping with the above, but in clock cycle 2, A[2]=62 is loaded into a register, in clock cycle 3 the register value is compared with REF=30 to generate a miss, and in clock cycle 4 the respective miss history is stored with HIS_FLAG=0. In clock cycle 5, when LOOP DECISION is executed, the stored HIS_FLAG is processed to identify the HIT_INDEX (at [i=1]) of the hit. Thus, while a hit is detected in clock cycle 2, at least one additional comparison occurs after this hit in clock cycle 3, but the history of all comparisons is stored and evaluated after all three comparisons are completed. The index location of the hit may again be implemented as a count, denoted HIT_INDEX. It starts with the earliest HIS_FLAG in time and continues to increment with each flag, stopping and validating when a set (HIS_FLAG=1) is encountered. In FIG. 3B, for example, the count goes to 0 for HIS_FLAG=0 from clock cycle 2, increments to 1 for HIS_FLAG=1 from clock cycle 3, and stops when the first hit is encountered. None of the history information stored thereafter, including HIS_FLAG=0 from clock cycle 4 in this example, is changed. Thus, by the time clock cycle 5 is completed, LOOP DECISION has determined that a hit occurred at index [i=1].

[0030] 3C, the process generally described above is again applied, with A[0]=16 loaded into a register in clock cycle 0, generating a miss in clock cycle 1, and storing that miss as HIS_FLAG=0 in clock cycle 2. Similarly, with a one clock cycle delay, A[0]=62 is loaded into a register in clock cycle 1, generating a miss in clock cycle 2, and storing that miss as HIS_FLAG=0 in clock cycle 3, and the same occurs for A[2]=22 after another clock delay. Thus, in clock cycle 5, LOOP DECISION evaluates the three stored HIS_FLAGs and determines that no hit occurred because each has a value of 0. This determination is illustrated, for example, in the counting technique described above for counting zero. Specifically, the HIT_INDEX count equals 0 for HIS_FLAG=0 from clock cycle 2, increments to 1 for HIS_FLAG=0 from clock cycle 3, and increments again to 2 for HIS_FLAG=0 from clock cycle 4. However, because no hit has occurred, the HIT_INDEX value of 2 is invalid. That is, the location of an array hit is not identified at this point because a hit has not yet occurred. Thus, by the completion of clock cycle 5, LOOP DECISION determines that no hit has occurred, e.g., based on all history flags being cleared, thereby invalidating the HIT_INDEX value. However, as shown in a later example, additional array search instructions may continue for larger arrays, in which case the HIT_INDEX counter may continue to increment from its current value (e.g., HIT_INDEX=2) until a hit is detected and verified as and when it is found.

[0031] In light of the foregoing, the example processor 100 of FIG. 1 and the example instruction progression 200 of FIG. 2 provide a structure and method by which an array may be searched using at least one comparison per successive clock cycle. This may be contrasted with alternative techniques that do not load elements for a subsequent iteration until the complete set of steps for the previous iteration, including the load, compare, and result actions performed for the previous iteration, delaying the load for the subsequent iteration and resulting in additional clock cycles compared to the processor 100. The described example may significantly reduce loop overhead, especially for large arrays or when hits occur anywhere beyond the first few locations in the array. This is because the described example performs a comparison per clock cycle, as opposed to prior art techniques that triple the clock cycles per array index and accumulate these tripled clock cycles per miss. Also, as further illustrated below, additional examples with additional scaling or parallelism may be implemented to achieve even greater performance and / or efficiency.

[0032] FIG. 4 illustrates an instruction progression 400 that follows the same axis definitions and includes the instruction progression 200 of FIG. 2. However, in FIG. 4, additional object code instructions are provided to illustrate the additional benefits of, for example, array lookups in larger arrays and concurrent instructions over more clock cycles. This is further discussed below by example in conjunction with FIG. 5. For example, while the diagram of FIG. 2 and the corresponding description show a LOOP DECISION in clock cycle 5, in FIG. 4, an additional instruction sequence is added before it in the same clock cycle. For example, in clock cycle 3, FIG. 2 shows a history store (STORE_COMP_HIS) for instruction sequence 1 and a reference compare (COMPARE A[1],REF) for instruction sequence 2. During the execution of these two instructions, a load (LOAD A[3]) for the next consecutive instruction sequence 3 is also added in FIG. 4. As another example, in clock cycle 4, FIG. 2 shows a history store (STORE_COMP_HIS) for instruction sequence 2. During execution of that instruction, a compare (COMPARE A[3],REF) for the next consecutive instruction sequence, 3, and a load (LOAD A[4]) for the next consecutive instruction sequence, 4, are also added in Figure 4. Thus, while Figure 2 shows a single execution of LOOP DECISION in clock cycle 5, the depiction of clock cycle 5 in Figure 4 shows instructions and larger arrays executing simultaneously, so that the LOOP DECISION for instruction sequences 0-2 occurs simultaneously with partial processing at different stages of three more instruction sequences (3, 4, and 5) during the same clock cycle. If the LOOP DECISION in clock cycle 5 determines that no hit has occurred in any of array elements A[0], A[1], or A[2] (as in search example 300_C of Figure 3C), then the array search for additional array elements A[3], A[4], and A[5] has already begun.

[0033] The above process continues throughout instruction progression 400 until the entire instruction progression is completed without a hit, or unless a hit is encountered and detected in the set of three array elements preceding the LOOP DECISION instance. For example, in clock cycle 8, another LOOP DECISION is executed, then processing the stored history for the sequence comparison of array elements A[3], A[4], and A[5]. If a hit occurs, which is indicated by HIS_FLAG=1, the index of the hit is identified, and instruction progression 400 may then branch elsewhere without executing some or all of the instructions shown after clock cycle 8. Conversely, if a hit does not occur, instruction progression 400 continues until clock cycle 11, at which point another LOOP DECISION is executed, then processing the stored history for the sequence comparison of array elements A[6], A[7], and A[8], thereby evaluating the stored history and detecting a hit and its corresponding index, or continuing again through the remaining clock cycles to clock cycle 14. Thus, in any of the above, comparisons can be performed in successive clock cycles for multiple array elements, terminating when a hit is found in a set of such array elements, the size of the set being determined by the frequency of the LOOP DECISION, and by the time clock cycle 14 is complete, a total of 12 array elements will have been loaded and compared, and any potential hits among them will have been found along with their indexes.

[0034] FIG. 5 illustrates an example search 500 using the instruction progression 400 of FIG. 4 in a search for array value 30. In the entirety of FIG. 5, example search 500 includes 12 array elements (elements indexed [0],

[10] , ...,

[11] ), where instruction progression 400 executes LOOP DECISION on successive sets of three array elements at a time, corresponding to three instruction sequences. Thus, over clock cycles 0-5, a first set of three array elements is loaded and compared to a reference REF, and a hit history including the aggregated value of HIS_FLAG is stored and then evaluated using LOOP DECISION. In the illustrated example, this first set produces no hits, i.e., HIS_FLAG=0 for each comparison, and LOOP DECISION, if implemented by a counter, increments for each HIS_FLAG=0, thereby bringing the HIT_INDEX count up to 2. Also during these clock cycles 0-5, i.e., clock cycle 3, instruction processing of a second consecutive set of three array elements begins, concluding with a LOOP DECISION evaluation in clock cycle 8. In the illustrated example, the second set also produces no hits, so a no-hit (miss) flag is stored with or added to the flag from the first set, and the LOOP DECISION, if implemented by a counter, increments every HIS_FLAG=0, thereby bringing the HIT_INDEX count up to 5. The same process continues for a third consecutive set of three array elements, with the counter continuing after clock cycle 11 at count 8, and then continues for a fourth consecutive set of three array elements, which begins and concludes in clock cycle 14. In clock cycle 14, LOOP DECISION increments the HIT_INDEX count from 8 to 9 due to a comparison miss to array element A[9], then increments the count from 9 to 10 due to a comparison hit to array element A

[10] , and stops any further increments, thereby verifying the HIT_INDEX count at that point.Thus, of the 14 clock cycles in instruction progression 400, most clock cycles include successive comparisons following a comparison in the immediately preceding clock cycle, thereby effectively reducing loop overhead when performing array searches.

[0035] FIG. 6 illustrates an instruction progression 600 that follows the same axis definitions and includes the instruction progression 200 of FIG. 2. However, in FIG. 6, additional parallelism is provided, in that each object code instruction operates on two different array elements simultaneously. This is further discussed by example below in connection with FIG. 7. This parallelism may be implemented, for example, in the structure and functionality of appropriate stages of instruction pipeline 104 of FIG. 1, e.g., the LOAD, COMPARE, and STORE_COMP_HIS instructions each have multiple operands corresponding to respective multiple array elements. For example, in clock cycle 0, the illustrated LOAD A[1], A[0] is intended to illustrate the pipeline processing of that instruction, so that, when executed, both array elements A[1] and A[0] are loaded into their respective registers (or respective portions of the same register) in the same clock cycle. Then, as a next example, in clock cycle 1, the illustrated COMPARE:A[1],REF;A[0],REF is intended to illustrate pipeline execution in which array elements A[1] and A[0] are each compared to REF in the same clock cycle. Then, as a final example, in clock cycle 2, STORE_COMP_HIS stores the history for both of the compared array elements. For example, while the previous example used a single bit for HIS_FLAG, in the example of FIG. 6, HIS_FLAG may use two bits, one for each value compared in the same instruction sequence in the immediately preceding clock cycle. To refer to such a multi-bit implementation, the flags may be represented as HIS_FLAG{mse,lse}, where operand mse is the higher-positioned array element being compared (A[1] in the current example) and operand lse is the lower-positioned array element being compared ([0] in the current example). This definition is an example; alternatively, each bit may be considered / implemented as a separate flag (e.g., HIS_FLAG1 and HIS_FLAG2).After the history is stored, as shown for example in clock cycle 5, LOOP DECISION evaluates these flags, consistent with the above description, to determine whether a hit occurred, and if so, the index of that hit, as further shown by the example below.

[0036] FIG. 7 illustrates an example array search 700, again using the instruction progression 600 of FIG. 6 in a search for array value 30. In its entirety, the example search 700 includes six array elements (indexed [0], [1], ..., [5]). However, using the parallelism of FIG. 6, two array elements are processed at a time. For example, in clock cycle 0, A[1]=16 and A[0]=65 are loaded, then in clock cycle 1, each loaded element is compared with REF=30, and then in clock cycle 2, a match history is stored for each. In the illustrated example, both comparisons in cycle 1 result in misses, so in clock cycle 2, HIS_FLAG{A[1],A[0]}=00 is stored. The clock cycles processing A[1] and A[0] overlap, so that in clock cycle 1, A[3]=62 and A[2]=83 are loaded, then in clock cycle 2, each loaded array element is compared with REF=30, and then in clock cycle 3, a match history is stored for each (so a flag is stored with or added to the flag from clock cycle 2). This generates two respective misses for these example values, so in clock cycle 3, HIS_FLAG{A[3],A[2]}=00 is stored. The clock cycles processing A[3] and A[2] overlap, so in clock cycle 2, A[5]=30 and A[4]=29 are loaded, then in clock cycle 3, each is compared with REF=30, and then in clock cycle 3, a match history is stored for each (so a flag is stored with or added to the flag from clock cycle 3). This results in one respective hit and one respective miss for these example values, so HIS_FLAG{A[5],A[4]}=10 is stored in clock cycle 4. Finally, in clock cycle 5, LOOP DECISION determines that a hit occurred and identifies index [i=5].Again, using the example of a counter for hit index detection, it starts with the earliest HIS_FLAG in time (lowest order) and increments, but when it encounters a set (HIS_FLAG=1) it stops at the count verified at that point.

[0037] Figure 8 illustrates an instruction progression 800 according to the same axis definitions as Figures 2, 4, and 6. However, in Figure 8, object code instructions are provided over additional clock cycles, with each instruction (and instruction sequence) targeting four different array elements, further expanding capacity compared to, for example, the single array element instructions of Figures 2 and 4, or the dual array element instructions of Figure 6. This additional element capacity may also be implemented in the structure and functionality of the appropriate stages of instruction pipeline 104 of Figure 1. For example, for the first instruction sequence, in clock cycle 0, LOAD A[3-0] illustrates a pipeline operation that, when executed, loads all four array elements A[3], A[2], A[1], and A[0] into their respective registers (or respective portions of the same register) in the same clock cycle. Then, as a next example, in clock cycle 1, COMPARE:A[3-0],REF compares REF with each of the four loaded array elements A[3], A[2], A[1], and A[0] in the same clock cycle. Then, as a final example, in clock cycle 2, STORE_COMP_HIS stores the history of all four compared array elements, thus storing a total of four bits. This can be consecutive bits stored in order of position importance, as previously described, or four individual flags. Also, partially overlapping the steps performed above with respect to the first set of four array elements, an equivalent series of steps is performed with respect to the second set of four array elements in clock cycle 1; this process is repeated in FIG. 8 for a total of nine instruction sequences, processing nine sets of four array elements each. Also, occasionally, for example, at a fixed period beginning at clock cycle 5 and repeated every three clock cycles, a LOOP DECISION is performed on the history of the 12 array elements that were previously loaded, compared to REF, and for which hit / miss history was stored.For example, in clock cycle 5, LOOP DECISION evaluates the flags corresponding to array elements A[0] through A

[11] , while in clock cycle 8, LOOP DECISION evaluates the flags corresponding to array elements A

[12] through A

[23] , and finally in clock cycle 11, LOOP DECISION evaluates the flags corresponding to array elements A

[24] through A

[35] . Again, each LOOP DECISION may terminate the search (branch from the search) if a hit is found in the array element processed before the LOOP DECISION, and, consistent with the discussion above, if a hit is eventually found, determine the index of that hit, as further illustrated by the example below.

[0038] FIG. 9 illustrates an example search 900 using the instruction progression 800 of FIG. 8 in a search for array value 30. In its entirety, example search 900 includes 36 array elements (indexed [0],

[10] , ...,

[35] ), and instruction progression 800 executes LOOP DECISION on successive sets of 12 array elements at a time, corresponding to three instruction sequences, where each instruction sequence includes four different array elements. Thus, over clock cycles 0 through 5, the first set of 12 array elements is loaded, compared to the reference REF, and the hit history is stored and then evaluated using LOOP DECISION. In the illustrated example, the first set does not produce a hit, i.e., HIS_FLAG=0 for each comparison (shown collectively as 0000 from index [3] through index [0]), and LOOP DECISION, if implemented by a counter, increments for each HIS_FLAG=0, thereby going up to a value of 11. Also during these clock cycles 0-5, i.e., clock cycle 3, instruction processing of a second consecutive set of 12 array elements begins, concluding with a LOOP DECISION evaluation in clock cycle 8. In the illustrated example, this second set also produces no hits, and LOOP DECISION, if implemented by a counter, increments each time HIS_FLAG=0, thereby going up to a value of 23. The same process continues for a third consecutive set of 12 array elements. However, when LOOP DECISION executes in clock cycle 11, a hit is detected for the third set of 12 array elements, i.e., at index 25. This is the count value when the count increments from 23 after the LOOP DECISION in clock cycle 8, for the next most significant non-hit value of HIS_FLAG corresponding to A

[24] =82, followed by the next most significant hit value of HIS_FLAG corresponding to A

[25] =30. Thus, in 11 clock cycles in instruction progression 700, a total of 32 array values ​​are evaluated for hit / miss, again effectively reducing loop overhead while performing array searches.

[0039] FIG. 10 is a flowchart of an exemplary array search method 1000 consistent with and summarizing certain principles described above. In the array search method 1000, step 1002 converts (e.g., compiles) an array search, e.g., expressed in a high-level computing language, into object code instructions to be processed in a processor pipeline. The object code instructions provide multiple concurrent flows 1004A, 1004B, ..., 1004Z; the example above illustrates three such concurrent flows, and the object code instructions further include a loop decision that follows the execution of a set of these flows. Each of the multiple concurrent flows has the same set of steps, operates simultaneously, and each flow is shifted in time relative to the other flows as they are processed through the processor pipeline. For example, a first flow 1104A may include loading one or more array elements 1006A, followed by comparing the loaded elements with a search criteria value 1008A, followed by storing the comparison results in history 1010A. Meanwhile, the second flow 1104B has the same steps but overlaps with them, beginning and ending later in time relative to the first flow 1104A. For example, load 1106B occurs simultaneously with comparison 1108A of the first flow 1104A, and comparison 1008B occurs simultaneously with history storage 1010A of the first flow 1004A. Finally, the second flow also has history storage 1010B, followed by comparison 1008B after history storage 1010A of the first flow 1004A. The same pattern and time delay can be repeated for any additional flows, such as flow 1004Z. Also, at some point after the set of steps of the first flow 1004A is completed, conditional step 1012 evaluates the history for multiple flows. Here, this history represents a current aggregation of several array elements compared to a reference value, and the comparison results are stored as an aggregate comparison history. If conditional step 1012 determines that the aggregate comparison history reveals only miscomparisons and that the array has not yet been completely searched, conditional step 1012 transfers control to continuation step 1014, which provides control to multiple flows 1004A, 1004B, ..., 1004Z, each of which continues the loop and processes one or more additional array elements.Conversely, if conditional step 1012 determines that the aggregate comparison history reveals a hit from the comparison or that the sequence has been completely searched, it passes control to completion step 1016. In completion step 1016, if a hit is found, the index of the first array element that hits in a comparison is determined, and method 1000 also completes without any additional processing by any of the multiple flows 1004A, 1004B, ..., 1004Z.

[0040] From the foregoing, the described examples provide an electronic processor structure and method that reduces overhead in processor array searches. The example processor includes a pipeline with stages, which may operate on one or more array elements in different examples. Array search instructions, for example from a high-level computing language, are converted into machine-level instructions that include certain steps that may reduce, and even significantly reduce, overhead in a pipeline architecture that performs array searches. Numerous examples are provided, and teachings are provided that may identify other examples. Accordingly, additional modifications in the described embodiments are possible, and other embodiments are possible, within the scope of the following claims.

Claims

1. 1. A processor, comprising: an instruction storage configured to store processor instructions; a data storage configured to store processor data representing an array, the array including a plurality of data elements; A controller; an instruction pipeline; Including, the instruction pipeline: a load stage circuit configured to load array elements from said data storage; a comparison stage circuit configured to compare the array elements with a reference value; a storage stage circuit configured to store a result set including the results of the comparison of the array elements with the reference values; a loop hit detection stage circuit configured to determine whether any of the set of results is associated with a hit against the reference value; a processor, including:

2. 2. The processor of claim 1, wherein the loop hit detection stage circuitry is further configured to determine, in response to a processor instruction, whether any of the set of results is associated with a hit against the reference value.

3. 2. The processor of claim 1, wherein the loop hit detection stage circuitry is further configured to determine an index of an array element that produced a match result in a comparison of the loaded array element with a reference value.

4. 2. The processor of claim 1, wherein the loop hit detection stage circuitry is configured to determine whether any of three sets of results is associated with a hit against the reference value.

5. 2. The processor of claim 1, wherein the load stage circuit is configured to load a third array element from the data storage simultaneously with the data of the compare stage circuit, the compare stage circuit is configured to compare a second array element with a reference value simultaneously with the store stage circuit, and the store stage circuit is configured to store a result set including a result of the comparison of the first array element with the reference value.

6. 2. The processor of claim 1, wherein the load stage circuitry is configured to load multiple array elements from the data storage during the same first clock cycle.

7. 7. The processor of claim 6, wherein the comparison stage circuitry is configured to compare each of the plurality of array elements to the reference value during the same second clock cycle.

8. 8. The processor of claim 7, wherein the store stage circuitry is configured to store the results of the comparison of each of the plurality of array elements with the reference value during the same third clock cycle.

9. 7. The processor of claim 6, wherein the plurality of array elements consists of two array elements.

10. 7. The processor of claim 6, wherein the plurality of array elements consists of four array elements.

11. 2. The processor of claim 1, wherein the loop hit detection stage circuitry is configured to determine whether any of a plurality of sets of results is associated with a hit against the reference value.

12. 2. The processor of claim 1, wherein the storage stage circuitry is configured to add a comparison history to a history corresponding to one or more previous executions by the storage stage circuitry.

13. 1. A method of operating a processor to search for a value in an array containing a plurality of elements, comprising: For each element of the plurality of elements, loading elements in each said array; comparing elements in each of said arrays with a reference value; storing a result of the comparison of elements in each of the arrays with the reference value; determining, from a set of results including a respective result associated with each element of the plurality of elements, whether any of the plurality of elements matches the reference value; A method comprising:

14. 14. The method of claim 13, further comprising determining an index of the array element that matched the reference value.

15. 15. The method of claim 14, wherein determining an index includes advancing a counter each time an element in the respective array is compared to a reference value, from a first comparison to a comparison that indicates a match of the element in the respective array with the reference value.

16. 14. The method of claim 13, wherein the storing includes storing a result of comparing a first array element with the reference value simultaneously with the loading of a third array element and the comparing of a second array element with the reference value.

17. 17. The method of claim 16, loading each said array element includes loading a respective plurality of array elements; comparing each array element with a reference value includes comparing each of the plurality of array elements with a reference value; storing the results includes storing a respective plurality of results corresponding to the comparison of the respective plurality of array elements. method.

18. 14. The method of claim 13, loading each array element includes loading a respective plurality of array elements; comparing each array element with a reference value includes comparing each of the plurality of array elements with a reference value; storing the results includes storing a respective plurality of results corresponding to the comparison of the respective plurality of array elements. method.

19. 1. A computer-readable storage medium having stored thereon instructions executable by a processor for searching for a value in an array comprising a plurality of elements, the instructions comprising: For each element of the plurality of elements, loading each said array element; comparing each array element with a reference value; storing a result of the comparison between each array element and the reference value; determining, from a set of results including a respective result associated with each element of the plurality of elements, whether any of the plurality of elements matches the reference value; will be carried out, A computer-readable storage medium.

Images