System and method for implementing a hardware-supported thread assist under load lookahead mechanism for a microprocessor

The present invention includes a system and method for implementing a hardware-supported thread assist under load lookahead mechanism for a microprocessor. According to an embodiment of the present invention, hardware thread-assist mode can be activated when one thread of the microprocessor is in a sleep mode. When load lookahead mode is activated, the fixed point unit copies the content of one or more architected facilities from an active thread to corresponding architected facilities in the first inactive thread. The load-store unit performs at least one speculative load in load lookahead mode and writes the results of the at least one speculative load to a duplicated architected facility in the first inactive thread.

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates in general to the field of data processing systems, and more particularly, the field of enhancing performance of data processing systems.

2. Description of the Related Art

There is a desire by computer users to maximize performance of microprocessors and a corresponding pressure on the computer industry to increase the computing power and efficiency of microprocessors. This desire is especially evident in the server computer field where entire businesses are dependent on their computer infrastructure to carry out and monitor day to day activities that affect revenue, and the like. Increased microprocessor performance will provide additional resources for computer users while providing a mechanism for computer manufacturers to distinguish themselves from the competition.

Over the years, state-of-the-art microprocessors have evolved from fairly simple systems to extremely complex integrated circuits with millions of transistors on a single silicon substrate. Early microprocessors were only able to execute one instruction per cycle. Today, “superscalar” microprocessors are able to execute more than one instruction per cycle.

As known in the art, certain situations result in instruction stalls where instruction execution is limited or halted until the situation is resolved. An example of such a situation is a cache miss that occurs when data required by an instruction is not available in level one (L1) cache and the microprocessor is forced to wait until the data can be retrieved from a slower cache or main memory. Obtaining data from main memory is a relatively slow operation, and when out-of-order execution is limited due to aforementioned complexities, subsequent instructions cannot be fully executed until valid data is received from memory.

More particularly, an older instruction that takes a long time to execute can create a stall that may prevent any subsequent instructions from executing until the time-consuming instruction completes. For example, in the case of a load instruction that requires access to data not in the L1 cache (cache miss), a prolonged stall can occur while data is fetched from a slower cache, or main memory. Without facilities to support all out-of-order execution scenarios, instruction order may not be changed such that forward progress through the instruction stream can be made while the missed data is retrieved.

In the Power6™ processor, a product of International Business Machines of Armonk, N.Y., the fixed point, load/store, and branch instructions are executed in-order with respect to each other. Therefore, when a load encounters a cache miss, subsequent instructions are stalled while waiting for the missed request to complete.

To overlap cache misses, a feature called load lookahead (LLA) execution is implemented in Power6™. Under LLA, when a load instruction cannot execute due to a translation or cache miss, subsequent instructions are allowed to execute if the subsequent instructions do not (directly or indirectly) depend on the load instruction. The LLA mechanism enables Power6™ to generate multiple data fetch requests to the lower cache structure and to bring data required by the subsequent instructions into the L1 cache.

Results under LLA executions are not saved. The results are available when the instructions execute and while they are being staged through the execution unit before the write back stage. While the instructions are being staged, the results can be forwarded to subsequent instructions, if necessary. When the result is passing through the write-back stage, the general-purpose register (GPR) location being set by the instruction under LLA is marked as “dirty”, because the results are discarded. Subsequent instructions utilizing the facility beyond the write-back stage cannot rely on the data since the architected location (e.g., GPR) was not updated by the older instruction.

Therefore, there is a need for a system and method for enabling subsequent instructions to utilize the results of the LLA executions beyond the write-back stage to address the aforementioned limitations of the prior art.

SUMMARY OF THE INVENTION

The present invention includes a system and method for implementing a hardware-supported thread assist under load lookahead mechanism for a microprocessor. According to an embodiment of the present invention, hardware thread-assist mode can be activated when one thread of the microprocessor is in a sleep mode. When load lookahead mode is activated, the fixed point unit copies the content of one or more architected facilities from an active thread to corresponding architected facilities in the first inactive thread. The load-store unit performs at least one speculative load in load lookahead mode and writes the results of the at least one speculative load to a duplicated architected facility in the first inactive thread.

The above, as well as additional purposes, features, and advantages of the present invention will become apparent in the following detailed written description.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

The present invention includes a system and method for implementing a hardware-supported thread assist under load lookahead mechanism for a microprocessor. According to an embodiment of the present invention, hardware thread-assist mode can be activated when one thread of the microprocessor is in a sleep mode. When load lookahead mode is activated, the fixed point unit copies the content of one or more architected facilities from an active thread to corresponding architected facilities in the first inactive thread. The load-store unit performs at least one speculative load in load lookahead mode and writes the results of the at least one speculative load to a duplicated architected facility in the first inactive thread.

Referring now to the figures, and in particular, referring toFIG. 1, there is illustrated an exemplary data processing system100in which a preferred embodiment of the present invention may be implemented. As illustrated, data processing system100includes microprocessors102a-102b, which are coupled to a system memory104via a system interconnect106. Those with skill in the art will appreciate that the present invention is in no way limited to two microprocessors, but any number of microprocessors may be implemented in data processing system100.

System memory104provides storage for data and instructions that are provided to, or received from microprocessors102a-102bvia system interconnect106. Data is then stored in L1 data cache and memory management unit (MMU)116. As well-known in the art, L1 data cache and MMU116provide smaller, but higher speed storage for information being utilized by a microprocessor such as microprocessors102a-102b. Bus interface unit (BIU)112enables communication between microprocessors102a-102band system interconnect106.

In accordance with the present invention, instructions are retrieved in order by sequential fetcher117from L1 instruction cache and MMU114and provided to instruction dispatch unit (IDU)111. Branch instructions are provided from sequential fetcher117to IDU111, which sends the branch instructions to branch processing unit (BPU)118. BPU118executes branch instructions that control the flow of the instruction stream by branching, or jumping, to another basic block of instructions. Conditional branch instructions evaluate a condition stored in a condition register and branch to another non-sequential instruction when the condition is satisfied and continue sequential instruction processing when the condition is not satisfied. Sequential fetcher117also includes branch prediction logic113that provides a prediction as to whether the branch will be taken or not, based on: (a) one or more hint bits, (b) the history of previously-executed branch instructions, or the like.

IDU111includes a64entry instruction buffer121, which receives the fetched instructions from sequential fetcher117. Instructions are stored in instruction buffer121while awaiting dispatch to the appropriate execution units. In an embodiment of the present invention, a dirty bit vector119in IDU111includes 32-bits, each bit corresponding to each of the 32 architected general purpose registers (GPRs)132in the microprocessor. It should be understood that a general purpose register having 32 entries is utilized merely as an example and should not be considered a limitation. Those skilled in the art will readily comprehend how general purpose registers (as well as other types of architected facilities such as floating point registers) of various sizes (e.g., 8, 16, 64, 128, and the like) are contemplated within the scope of the present invention.

The bits in dirty bit vector119will indicate which results in GPRs have valid or invalid results. In an embodiment of the present invention, a “0” will be set in a dirty bit vector for those registers having valid results and a “1” will be set in a dirty bit vector for those registers having invalid results. Dirty bit vector119will be described in more detail herein in conjunction withFIG. 3.

IDU111dispatches instructions to various execution units, such as a fixed point, or integer unit (FXU)122and floating point unit (FPU)130. Both FXU122and FPU130are arithmetic/logic units that perform various functions, such as ADD, SUBTRACT, MULTIPLY, and DIVIDE. Basically, fixed point arithmetic differs from floating point arithmetic in that scientific notation is possible with floating point operations because the radix point is capable of being moved among the digits of the number. In contrast, fixed point arithmetic implicitly sets the radix at a particular place. Fixed point and floating point arithmetic is well-known to those skilled in the art and will not be discussed further herein.

Load store unit (LSU)128executes instructions that either load information (data and instructions) from memory to the microprocessor registers or store information from those registers into memory. GPRs132are associated with FXU122and floating point registers (FPRs)136are associated with FPU130. These registers store the arithmetic and logical results from execution of the instructions by their respective execution units. As depicted, IDU111is coupled to all of the execution units and registers such that any type of instruction can be dispatched from IDU111. Further, the output of the execution units122,128, and130are coupled to the general purpose registers (GPRs)132and floating point registers (FPRs)136such that the execution units can store results to the registers from executed instructions and then retrieve those results to be used in processing existing or future instructions. The elements shown in microprocessor102aand described above can be considered to constitute the “core” of a microprocessor. Also, the present invention includes the utilization of microprocessors that may include multiple cores, which may include multiple execution units.

Referring toFIG. 2, dirty bit vector119is shown with its relationship to GPRs132. Each of the 32 bits in vector119represent the values in the 32 GPRs132(i.e., Bits 0-31 in dirty bit vector119directly correspond to registers 0-31 in GPR132. For purposes of explanation and not limitation, vector119is described herein as being associated with GPR132. It should be understood that other embodiments of the present invention are contemplated in which a dirty bit vector is associated with FPRs136. In the case of data processing systems that support multi-threaded processing, there is a corresponding dirty bit vector119and GPRs132for each thread.

FIG. 3shows a set of bits that indicate the dependency of speculatively executing instructions relative to one another. These “dependency on delayed validation” bits can monitor various conditions such as the dependency by a current instruction on a prior instruction that moves data between registers within the microprocessor, or by an instruction that uses data written to a register by an I/O device. In an embodiment of the present invention, the “dependency on delayed validation” bits will monitor the dependency of a current instruction on the data retrieved by a load instruction. These “dependency on load” (DL) bits are used to track the time between when a load instruction returns the result and when the result is determined to be valid.

For purposes of simplifying the understanding of the present invention, the “dependency on load” (DL) bits will be used as one example of the “dependency on delayed validation” bits. However, it should be noted that other embodiments may have different or additional dependency bits to track the distance between the validation of other sources of data (beyond load instructions) and the dependent instruction.

The dependency on load example is used herein for the purposes of illustration only and not limitation. The DL bits are essentially a shift counter having a number of bit positions equal to the number of cycles between the time the load data is returned and when the validity of the data is subsequently determined.

InFIG. 3, reference numerals150,151each represent three DL bits that correspond to first and second LSUs, respectively. Further, dirty bit vector152that is associated with the result being processed by the load instruction is a continuation of the dirty bit in dirty bit vector119that is associated with an architected register. This dirty bit “D” in the instruction is also determined, not only by the value in dirty bit vector119, but also by various other inputs. These include the DL bits, a load reject, which is an indication of whether load data is valid, forwarded dirty bits from other instructions, and the like.

Further, with regard toFIG. 3, field153will be used in the case where multi-threading is implemented. That is, the processor will need to know which of the two (or more) threads is being executed in order to track the resources, i.e. context of each thread. This bit or an equivalent indicator will be present for all multithreaded implementation, regardless of whether the threads are capable of utilizing the load lookahead prefetch mechanism of the present invention. Finally, a speculative field157includes a tag bit that tells the processor whether the instruction is being executed speculatively, i.e. “S”.

FIG. 4Ais an illustration of an instruction capable of being implemented by a microprocessor that operates in accordance with the present invention. Reference numeral156is an opcode that defines the type of operation being performed, such as an ADD, COMPARE, LOAD, or the like. RT155is the target register where the results of the operation are stored. Registers RA154and RB158are two source registers having the operands that are to be manipulated in accordance with the opcode of the instruction. Speculative execution tag bit157is included to indicate whether the instruction is being speculatively executed and will not write its results back to the architected registers, or non-speculatively executed where write back is enabled. Dirty bit152and DL bits150,151, multithreaded bit153, as well as speculative execution bit157have been described above with reference toFIG. 3.

Load lookahead prefetch is started whenever a load (or other instruction that takes a lot of cycles to execute) causes an extended stall condition such that the out of order facilities, if any, provided by the processor can not support further progress through the instruction stream. Once active, load lookahead prefetch accomplishes three things:

(1) allows the execution of instructions without changing the architected state of the machine;

(2) determines which loads are eligible to be prefetched; and

Once lookahead prefetch mode is activated, instructions that are not supported by the out-of-order execution mechanisms of the processor (if any), identified herein as “speculative instructions”, are allowed to be written back to a copy of the architected registers of the microprocessors stored in an inactive thread. The copy of the architected registers and writeback are discussed in more detail in conjunction withFIG. 4B.

In any case, determining which loads are eligible for prefetching requires that instruction dependencies and the validity of results be tracked. This functionality is split into two parts. Execution units are responsible for dynamically tracking dependencies related to instructions in the execution pipeline using a set of “Dirty” (D) and “Dependency on Load” (DL) bits. For the purpose of example and not limitation, invalid or unavailable results, particularly for those speculative instructions that are no longer in the pipeline, are tracked in this preferred embodiment by IDU111. Other embodiments may track invalid or unavailable architectural facilities in the execution units, or with the architectural facility.

Load lookahead prefetch continues until the initial stall condition is resolved. In the case of a load causing a cache miss, this could be a signal indicating that the load data is now available. When this occurs, normal non-speculative execution will restart at the stalled instruction. Any information about speculative result validity tracked by load lookahead is cleared at this time.

Referring now toFIG. 4B, GPR132is implemented as a sixty-four entry register file. The GPR of two threads (an active thread and an inactive thread) are interleaved such that GPRs of thread0occupy the even entries of the register file and GPRs of thread1occupy the odd entries of the register file. When IDU111enables hardware-supported thread assist, one of the threads is in an inactive or “sleep mode”. For example, thread1may be in an inactive mode while thread0remains active. Then a “copy_unconditional” signal158enables the copying of the contents of the architected registers for thread0to thread1. In an embodiment of the present invention, “copy_unconditional” signal158may be sent from IDU111or activated by software. Then, during load lookahead prefetching, as instructions pass through the execution unit pipelines and the entire the writeback stage, results of the speculative execution of the instructions are written to the copy of the content of the architected registers in thread1. In effect, thread1acts as a “scratchpad” for speculative results so that newer instructions dispatched from IDU111can also utilize the results of older instructions to prefetch needed information from system memory106until the stall condition that triggered the hardware-supported thread assist load lookahead prefetch has been resolved.

FIG. 5is an overview of the present invention showing the various circuit elements used in the microprocessor (e.g., microprocessor102a-102b) utilizing hardware-supported thread assist load lookahead prefetch according to an embodiment of the present invention. Microprocessor instructions ready for dispatch are held in dispatch latch160. These instructions were provided to instruction buffer121in IDU111and have been processed by instruction sequencing logic prior to being received in latch160. The instruction is then dispatched from latch160to its appropriate function unit168, such as LSU, FPU, FXU or the like, and latched in by latch169. Source lookup logic162within dirty bit logic161also receives the instruction via latch166, and determines if the source registers contain invalid data. If so, a dirty bit value is provided to dirty bit latch163. As noted above, the dirty bit will be provided along with the instruction to the various pipeline stages encountered during instruction processing. Dirty bit logic161will be described in greater detail in accordance withFIG. 6.

The dirty bit tracking and dependence on load (DL) logic165then receives the dirty bit from latch163and stores the dirty bit in latch164. Those skilled in the art will appreciate how bits of data are latched across logic boundaries in order the keep the various processing elements in synchronization with each other.

Tracking logic167is also shown as part of dirty bit tracking and DL logic165. Tracking logic167receives several inputs175,176,177and outputs a dirty bit signal on line174based on the state of the various inputs175,176,177. The dirty bit from bit vector119is input to tracking logic167from IDU111, via latch164, which represents one of possibly several latches used by the present invention to ensure correct timing and synchronization. A signal175representing the reject status of a load instruction (i.e., whether the load data is valid) is also received by tracking logic167. There are three criteria which will cause the dirty bit on line174to be set.

(1) Source data marked as “dirty” is forwarded from another instruction in functional unit168to tracking logic170via DL bits176and177(i.e., from mux170);

(2) IDU111determines the source operand is dirty from the associated bit in dirty bit vector119and data is read from the GPR; and

(3) Source data is read from a load that is later determined to be invalid (load reject) as received on input line175and the LSB of the DL bits is “1”.

More particularly, when the data is determined to be “invalid”, a reject signal is input at the appropriate time via line174to tracking logic167such that the dirty bit value is updated. Input lines176,177provide the dirty bit and DL bits from source multiplexer170. As noted above, the dirty bits and DL bits are forwarded with each instruction as the instruction progresses through the pipeline. Line174will provide these bits back to source multiplexer170after each stage.

As will be described in more detail below, the DL bits function as a shift counter with the number of bits being dependent on the cycles needed to validate the load data. The most significant bit (MSB) is initially set and then subsequently shifted as each pipeline stage is traversed. When the least significant bit (LSB) is set, then the determination of the validity of the load data is completed and it will be known whether a load reject has occurred. The operation and use of the DL bits will be described more fully below.

Functional unit168includes the pipeline stages commonly found in the vast majority of microprocessors, such as decode, execute (arithmetic and logic operations), writeback, and the like. Source multiplexer170receives input from GPR132, from latches171,172, and173associated with each stage, and the dirty and DL bits from tracking logic167via line174. It should be noted that line174inFIG. 5represents multiple dirty bit signals, since tracking logic167needs an output from each stage to that stage's own bypass multiplexer. The dirty and DL bits are then added to the instruction by source multiplexer170as the instruction enters the pipeline of functional unit168. Adding the dirty and DL bits places the instruction in the format as shown inFIG. 4A. By way of example, but not limitation, latch169could be considered the “decode and read” stage, latches171and172could be considered execute stages, and latch173could be considered the writeback stage.

FIG. 6shows the checking and updating functions associated with dirty vector119in IDU111. More specifically, dirty bit vector119will be maintained to keep track of which results are no longer available for forwarding. The number of bits in dirty bit vector119is dependent on the number of architected registers present in the processor.

At dispatch time, every instruction will lookup the necessary source registers (RAand RB) in dirty bit vector119to determine if any of the source registers are to be considered invalid. Other embodiments may lookup the dirty state of the register vector (or other architectural facility) at the time that the register is accessed. All of the bits in dirty bit vector119are initially set to “0” and these bits are set to “1” when a value contained in the corresponding register is determined to be invalid or “dirty”. Source logic162looks up the dirty bits in dirty bit vector119for registers associated with the instructions being dispatched and a dirty bit is then forwarded to the function units via latch216. The instruction dirty bit in functional unit168(FIG. 5), which is an indication that one or more data sources for an instruction are invalid, can be set in one of three ways:

(1) Source data is read from a forwarding path and that data is already marked dirty (dirty bit from an instruction in the pipeline is forwarded);

(2) IDU111(FIG. 1) indicates that a source operand is dirty based on a lookup in the dirty vector119; or

(3) Source data was read from a load that later determines the data is invalid and sends a reject signal (DL bits indicate that LSB is “1” and load reject occurs).

The dirty bit is forwarded along with results to any dependent instruction. If an instruction utilizes multiple sources, the dirty bits can simply be logically ORed together. That is, if an instruction is utilizing RAand RB, then the dirty bits for these two registers are ORed and if one bit is set, then the data resulting for the execution of the instruction is considered invalid. LSU128will block cache access when a load with its dirty bit set is encountered.

As shown inFIG. 6, instructions ready for dispatch are stored in latch160and then provided to another latch211, as well as to the execution units. Validate and combine target register logic213, via decode212, also receives instructions from the writeback stage subsequent to latch217and prior to the instruction being provided to writeback latch218. Specifically, validate and combine target register logic213determines if the instruction associated with the target register is considered invalid and whether the result of that instruction should be marked dirty. Validate and combine target register logic213determines:

(1) If load lookahead prefetch mode is active;

(2) Whether the instruction is considered valid;

(3) Whether there are multiple threads in the processor and which thread is current (i.e., the dirty bit needs to be written to the dirty bit vector of the correct thread); and

(4) Whether the register contains valid data based on the dirty bit coming from the execution unit.

If the four previous considerations are true, the dirty bit for that instruction is set. The instructions are provided to source lookup logic214, which examines the source registers and utilizes dirty bit vector119to determine whether the data is valid.

A logical “1” will be associated with the instruction being processed when the source data is invalid and a “0” will be associated with the instructions if the source data is valid. Of course, these bit values are merely exemplary and other patterns are contemplated by the scope of the present invention to indicate the validity of the instruction data. Validate dirty bits logic215then validates the dirty bit by determining if lookahead mode is active, the instruction is valid and whether the correct thread is being utilized. The dirty bit is then provided to latch216to be subsequently supplied to the instruction in the execution unit. It can be seen that the instruction is initially provided to both the dirty bit logic and the execution units. Once the dirty bit logic determines the appropriate state of the bit, the state is supplied to the instruction as the instruction proceeds through the execution pipeline.

FIG. 7shows in greater detail the logic utilized in conjunction with the tracking of the dirty and DL bits. To improve performance, load/store units in one embodiment return load results before having determined if those results are actually valid. If the load results are determined not to be valid, a “reject” signal is provided to indicate this invalid state. If the state is determined to be “invalid”, a situation is created where a newer, dependent instruction may have already utilized the returned load result as source data before that data is determined to actually be valid.

Dependence on load (DL) bits are utilized within the execution units to indicate the occurrence of such a condition. The DL bits function as a shift counter that counts down the time, in microprocessor cycles, between when a load instruction returns a result from memory and when the load instruction can send a reject signal, if the load data is determined to be invalid. In the case where the load data is determined to be valid, then no reject signal is sent and processing is allowed to continue. The length of the time window between the time when the load instruction returns a result from memory and when the load instruction can send a reject signal, and accordingly, the number of DL bits required is specific to the implementation of LSU128(FIG. 1). In the case of microprocessors having multiple LSUs, a set of DL bits must be maintained for each LSU. The DL bits are set whenever an instruction receives forwarded data from another instruction in the pipeline. The number of sets of DL bits will correspond to the number of LSUs present in the microprocessor. In this manner, the DL bits from a particular LSU will indicate the validity of load data for that particular LSU. Once an instruction has passed the latest point, in terms of cycles after the load result is received, where the instruction could be rejected, the DL bits are no longer needed.

In accordance with the present invention, the DL bits are set as follows:

(1) An instruction that utilizes the forwarded result of a load instruction as early as the result is available will set the MSB of the corresponding DL bits;

(2) An instruction that utilizes the forwarded result of a load instruction one cycle after the result is available will set the second MSB of the corresponding DL bits;

(3) An instruction that utilizes the forwarded result of a load instruction n cycles after the result is available will set the nth MSB of the corresponding DL bits; and

(4) An instruction that utilizes a forwarded result of a non-load instruction will copy that instruction's DL bits.

The DL bits are then shifted every cycle. When a reject signal from an invalid load is encountered, the least significant DL bits of any dependent instruction will indicate that the dependent instruction depends on the rejected load. The dependent instruction can be marked, utilizing the dirty bit, as having invalid source data. If the instruction receives data from a load that has already passed the validation stage, then the instructions will get a dirty bit from the load at the time of the result bypass. Result data from a rejected load will be marked as dirty such that any dependent instruction that receives the result data via a forwarding path will identify the data as dirty.

Returning toFIG. 7, the instruction flow through the various logic and latches associated with four pipeline stages is shown. It should be noted that four stages are utilized merely as an example and any number of implementations having different stages are possible and are contemplated by the scope of the present invention. At stage A, a load instruction reads the data from the GPR or forwarding path and receives an indication of the status of the data (by forwarded dirty and DL bits). At this time, data read from the GPR is unknown to be valid or invalid. Also at stage A, logic220is utilized to copy the dirty bit associated with the instruction being executed from the output of a subsequent stage (stage B, C, or D in this example). This dirty bit may have been received from latch216in IDU111(FIG. 6) and placed into latch219before being provided to set dirty bit logic228in stage C.

It should be noted that a number of cycles must elapse before the dirty bit value to be supplied from IDU111to the execution units. Other embodiments may not have such a delay as the dirty bit may be kept with the data in a register file, or elsewhere in the vicinity of the execution units. The delay is the reason why the dirty bit is not provided until stage C. Additionally, conditions in the functional units (e.g., FXU) may cause the dirty bit to be set when the appropriate inputs are provided to set dirty bit logic224and228. These conditions include the LSB of the DL set to “1” coupled with a load reject signal, or a forwarded dirty bit from an older instruction. Referring back to stage A, the dirty bit from logic220is then placed in latch222. DL bit generation logic221receives the forwarded DL bits from a previous instruction and sets the bits in latch223.

In stage B, set dirty bit logic224receives the dirty bit from latch222and DL bits from latch223as well as a reject signal from line33. The least significant bit of the DL bits (variable A), from latch223is ANDed with the reject signal from line33(variable C). The result of the AND operation is then ORed with the dirty bit (variable B) to determine if the source registers associated with the instruction contain valid data. That is, the logical function (A AND C) OR B will determine whether the data is valid. As noted above, the DL bits function as a shift counter with the most significant bit originally set. The bit is then shifted until the bit reaches the LSB position, at which time, the load data is known as valid or invalid. Right shift logic225performs the shift counter function at stage B and right shifts the DL bits before sending the DL bits to latch227and forwarding the bits back to generation logic221. The result of the above AND/OR operation is provided to latch226, as well as logic220.

Stage C performs the same essential functions as stage B. Latch227provides the DL bits to shifting logic229and dirty bit setting logic228. Logic228ANDs the least significant DL bit (variable A) from latch227with the load reject signal from line233(variable C). The dirty bit from latch226(variable B) is then ORed with the result from the AND operation between the DL bit and the load reject, and the result is provided to dirty bit latch230and dirty bit copy logic220. The resulting DL bits output from logic229are provided to latch231and also forwarded back to stage A and input to logic221. The processing continues until the writeback stage D is encountered. The results from the instructions in the writeback stage are written to an inactive thread (e.g., thread0inFIG. 4Bthat holds a copy of the content of the architected registers).

FIG. 8illustrates in more detail the logic implemented by the “set dirty bit” logic224and228ofFIG. 7. In an embodiment of the present invention, two load/store units (L/S 0 and L/S 1) are present such that two sets of DL bits will be provided, one for each load/store unit. More particularly, the DL bits from a prior instruction are shown by reference numbers300and301. LSB positions from DL fields300and301, respectively, are coupled to AND gates306and307, respectively. These AND gates also receive inputs indicating whether the load operations from L/S 0 and L/S 1 are rejected, i.e., whether the load data is invalid. As shown inFIG. 8, if the DL LSB is set to “1” and the loads are rejected (set=“1”), then a “1” output is provided to OR gate308. When loads are rejected for either load/store unit and the load data is not valid, then a “1” is provided from AND gates306and307to OR gate308.

Further, a dirty bit302from dirty bit vector119corresponding to the register addresses from the instruction being executed is read and input to AND gates309and310. For example, when an instruction utilizes registers RAand RB, the associated dirty bit from dirty bit vector119is utilized as an input to AND gates309and310. It is also determined whether the registers RAand RBare read from the register file (e.g., GPR for operations). It should be noted that the present invention contemplates any type of register file and a GPR is used herein only for purposes of explanation. If the registers used by the instructions are read from the register file (e.g., CPR), then a “1” is input along with the corresponding dirty bit value into AND gates309and310, respectively. It can be seen that when the operand is read from the register (e.g., RA) and the dirty bit corresponding to RAis set, then a logical “1” output is provided from AND gate309to OR gate308. Similarly, when RBis read from the GPR and the corresponding dirty bit from dirty bit vector119in IDU111is set, then a logical “1” will also be provided to OR gate308from AND gate310.

The outputs from AND gates306,307,309,310, along with the dirty bit302forwarded with result data, such as a source operand from any previous instruction are then ORed together. If any one of these inputs is true (e.g., set equal to “1”), then the dirty bit305is set and forwarded to a newer instruction in the pipeline. If none of the inputs to OR gate308are true, then the dirty bit is not forwarded and the DL bit in fields303and304are shifted to the right, since the dirty bit would not have been in the least significant bit position. In this manner, the present invention can track the status of the dirty bit for instructions proceeding through the pipeline stages of the microprocessor.

FIG. 9is a high-level logical flowchart illustrating an exemplary method of implementing hardware-supported assist under load lookahead mechanism for a microprocessor according to an embodiment of the present invention.

The process begins at step900and proceeds to step902, which depicts IDU111determining if the present instruction for dispatch is a load instruction. If the present instruction for dispatch is not a load instruction, the IDU111dispatches the instruction to the appropriate execution unit (e.g., FXU122, FPU130, etc.) and proceeds to the next instruction, as illustrated in steps903and904. The process then returns to step902.

Returning to step904, if the present instruction is determined to be a load instruction, the process continues to step905, which shows IDU111dispatching the load instruction to LSU128. The process proceeds to step906, which depicts LSU128determining whether a load reject condition has occurred.

As previously discussed, an example of a load reject condition is when an in-order execution microprocessor determines that load data is invalid, due to a cache miss, address translation table miss, or the like. The cache miss generally creates a stall condition since execution cannot proceed until the data becomes available. If there is no stall condition, LSU128processes the received load instruction, as illustrated in step907, and the process continues to step904, which illustrates IDU111examining the next received instruction. The process returns to step902.

If a load reject condition has occurred, the process continues to step908, which depicts IDU111initiating a load lookahead prefetch. The process proceeds to step910, which determines if there is an inactive thread available to be used for hardware-supported thread assist. If there is such an inactive thread, the process proceeds to step912, which illustrates the initiation of hardware-supported thread assist. Then, LSU128copies the content of the architected facility of the active thread (e.g., thread0) to the corresponding facility of the inactive thread (e.g., thread1), as shown in step916. In an embodiment of the present invention, the aforementioned copying process is accomplished in one processor cycle. If there is not an inactive thread available in step910, hardware-supported thread assist cannot be used and normal lookahead mode is enabled instead, as illustrated in step914.

The process continues to step918, which illustrates LSU128determining if the load data requested in step902is ready for processing. If the requested load data is not ready, the process continues to step925, which depicts instructions being processed in load lookahead mode. This flow is described in more detail inFIG. 10beginning with step1000. The process returns to step918and continues in an iterative fashion.

At step918, if the load data requested in step902is ready for processing, the process proceeds to step922, which depicts LSU128exiting hardware-supported thread assist load lookahead prefetch mode. The process continues to step924, which illustrates ISU111clearing dirty bit vector119. The process proceeds to step926, which shows LSU922non-speculatively executing the load instruction originally rejected in step906. The process returns to step902.

Those with skill in the art will appreciate that while an embodiment of the present invention includes load instructions that are sent to LSU128in a reduced instruction set computer (RISC) microprocessor, the system and method of hardware-supported thread assist load lookahead prefetch of the present invention may also load instructions sent to any functional unit (e.g., FXU, FPU, etc.) within any type of microprocessor, including, but not limited to a Complex Instruction Set Computer (CISC) microprocessor.

FIG. 10is a high-level logical flowchart depicting an exemplary method of load lookahead prefetch according to an embodiment of the present invention. For ease of discussion, the left side ofFIG. 10generally depicts functions performed by the execution unit (e.g., LSU128). The right side ofFIG. 10generally illustrates functions performed by IDU111. The process begins at step1000, and continues to step1002, which illustrates IDU111dispatching an instruction to the appropriate execution unit. For example, IDU111will dispatch a load instruction to LSU128. After the instruction is received, IDU111looks up the registers that are being called for at the data or operand sources for the instruction in dirty bit vector119, as shown in step1054. The process continues to step1056, which illustrates IDU111determining whether the source data is dirty, by examining dirty bit vector119.

If the dirty bits are set (indicating invalid data), the process continues to step1058, which illustrates IDU111forwarding the dirty bits along with the instruction to the appropriate execution unit (e.g., LSU, FPU, FXU) for inclusion into the instruction. For example, with an ADD instruction, the target register (Rt) would be the register which will received the result of the addition of the values from the source registers and the dirty bit will be forwarded to a present instruction from a prior instruction that used the same target register but had invalid results.

After step1058, the process continues to step1034, which depicts the IDU111determining whether or not the instruction has reached the writeback stage. If the instruction has not yet reached the writeback stage within the execution unit, the process returns to step1034and proceeds in an iterative fashion until the writeback stage is reached. At this point, the process continues to step1048where the dirty bits associated with any results written are received by the IDU111. These dirty bits are sent to the IDU111from the execution unit in step1040. The process continues to step1050, which illustrates IDU111using these dirty bits to determine if the result is valid. If a dirty bit is set and the result is not valid, then the corresponding entry in the dirty vector119is set in step1052and the process continues to step1053. Otherwise, if the result is valid and there is no dirty bit set associated with that result, then the process continues to step1053, which shows the IDU111determining if the hardware-supported thread assist load lookahead prefetch mode should be exited. As previously discussed, the hardware-supported thread assist load lookahead prefetch mode is exited when the stall condition that started the mode is resolved. If the mode should be exited, the process ends, as illustrated in step1060. If the mode should not be exited, the process returns to step1002.

Parallel with step1054, after IDU111dispatches the instruction, the process continues to step1004, which illustrates the execution unit determining whether the source data is forwarded from a prior instruction. If the source data is provided from the forwarding path, then the process continues to step1006, which depicts DL bits being set, i.e., the DL bits are initialized to, for example,100, when three cycles are required to determine the validity of the load data. The process proceeds to step1008, which shows the execution unit determining if the source registers are dirty (a dirty bit was forwarded). If a dirty bit was forwarded, the process continues to step1010, which illustrates the dirty bit being set for the present instructions (i.e., the dirty bits are forwarded to more recent instructions). The process then continues to step1012. If the source registers are not dirty, the process continues directly to step1012.

Returning to step1004, if source data is not forwarded from a prior instruction, the source data is read from a general purpose register (e.g., GPR132inFIG. 1) and the process continues to step1012, which illustrates the execution unit determining if the source data read from the copy of the architected registers located in the inactive thread (steps910-914ofFIG. 9) is dirty with the help of the dirty bits sent from the IDU111in step1058. If the source data is dirty, the execution unit sets dirty bit field152(FIGS. 3 and 4A) within the instruction, as illustrated in step1014. The process continues to step1016.

Step1016illustrates a determination made by the execution unit executing the instruction whether a load reject signal has been received from LSU128. As previously described, the load reject signal indicates that data loaded from the cache is invalid. If the execution unit has received a load reject signal from LSU128, the process continues to step1018, which depicts the execution unit determining if the lowest DL bit151is set. If so, the dirty bit field152within the instruction is set by the execution unit, as shown in step1020. When the LSB of the DL bits is set, the dependency between the instructions in the pipeline is known. The dirty bit can be set when the data reject signal for a corresponding load instruction is also known. The process continues to step1022.

In step1022, if the instruction is a load instruction, the process continues to step1024, which depicts the execution unit determining if the dirty bit field152in the instruction is set. If so, LSU128blocks access to the cache in step1026(e.g., L1 data cache and MMU116), preventing invalid data that was retrieved using dirty source operands from being written.

If the instruction is not a load instruction or the dirty bit is not set, the process continues to step1028, which illustrates the execution unit determining if the point in time where a load reject is past. This point varies by implementation but in this embodiment is the time when the data valid is returned from LSU128, indication that the data returned at an earlier point in time from a cache access is in fact valid. If not, the process continues to step1030, which depicts the execution unit shifting the DL bit s150and151(FIGS. 3 and 4a), to continue to track the validity of instruction being processed by the execution unit. After this shifting occurs, the process returns to step1016to once again wait for a reject signal. This cycle repeats until the data valid is returned from LSU128and there can no longer be a reject signal. If the time where a load can reject is past, the process proceeds to step1032, which shows the execution unit dropping the DL bits150and151(FIG. 3andFIG. 4A), because there is no longer a need to track the progress of the instruction relative to the validity of the target and source registers.

After step1032, the process continues to step1036, which determines if the instruction has reached the writeback stage. If the instruction has not yet reached the writeback stage within the execution unit, the process returns to step1036and proceeds in an iterative fashion until the writeback stage is reached. Once the writeback stage has been reached, the process continues to step1038, which illustrates the execution unit writing the results in the copy of the content of the architected registers located in an inactive thread (e.g., thread1, as depicted inFIG. 9). Finally, continuing to step1040, the value of dirty bit field148is sent to the IDU111where it is received by step1048.

As discussed, the present invention includes a system and method for implementing a hardware-supported thread assist under load lookahead mechanism for a microprocessor. According to an embodiment of the present invention, hardware thread-assist mode can be activated when one thread of the microprocessor is in a sleep mode. When load lookahead mode is activated, the fixed point unit copies the content of one or more architected facilities from an active thread to corresponding architected facilities in the first inactive thread. The load-store unit performs at least one speculative load in load lookahead mode and writes the results of the at least one speculative load to a duplicated architected facility in the first inactive thread.

It should be understood that at least some aspects of the present invention may alternatively be implemented in a computer-usable medium that contains a program product. Programs defining functions in the present invention can be delivered to a data storage system or a computer system via a variety of signal-bearing media, which include, without limitation, non-writable storage media (e.g., CD-ROM), writable storage media (e.g., hard disk drive, read/write CD-ROM, optical media), system memory such as, but not limited to random access memory (RAM), and communication media, such as computer and telephone networks including Ethernet, the Internet, wireless networks, and like network systems. It should be understood, therefore, that such signal-bearing media when carrying or encoding computer-readable instructions that direct method functions in the present invention represent alternative embodiments of the present invention. Further, it is understood that the present invention may be implemented by a system having means in the form of hardware, software, or a combination of software and hardware as described herein or their equivalent.