Patent Application
20070226470
1. Field
The present disclosure pertains to the field of information processing, and, more specifically, to the field of memory access management.
2. Background
In some prior art microprocessors or processing systems, information (data or instructions) may be accessed by a microprocessor using such operations as “load” operations or “store” operations. Furthermore, load and store operations may be performed in response to an instruction (or sub-instruction, such as a micro-operation, or “uop”) being executed by a processor. In some processing architectures, load instructions may be decoded into one uop, whereas store instructions may be decoded into two or more uops, including a store address (STA) uop and a store data (STD) uop. For the purpose of this disclosure both store uops and instructions will be referred to as “store operations” or “stores” and load uops and instructions will be referred to as “load operations” or “loads”.
In some processors or processing systems, a number of load and store operations may be executed, or otherwise pending, concurrently. For example, in a pipelined processor containing multiple processing stages that may each operate on different operations concurrently, there may be several load and store operations being performed concurrently, each at a different stage within the pipeline. However, at various pipeline stages, the address from where data is to be loaded by load instructions or to where data is to be stored by store instructions (collectively referred to as “target address”) is unknown, or “ambiguous”. This is because the target address of load and store instructions or uops are sometimes determined after the load or store has already begun to be executed.
When load and stores (e.g., STA uops) are dispatch from the reservation station, they may be sent to the address generation unit, which generates a corresponding linear address for the load and stores to be sent to memory or cache. Load operations are typically dispatched from the reservation station into a load buffer within memory ordering buffer (MOB), where the loads are checked for conflicts and dependencies with other store operations. If no conflicts or dependencies with stores exist, the load may be dispatched to the memory/cache cluster. Otherwise, the load may have to wait in the MOB until the dependencies and/or conflicts are resolved before being dispatched to memory/cache.
Once the loads are dispatched to memory/cache, the memory/cache may return data targeted by the load to the execution unit reservation station, which may use the loaded data to generate an address to the nextas operand of some successive uop to be dispatched from the scheduler/reservation station.
Store operations, which may include STA uops, may follow a similar path as loads. However, stores are not typically allowed to be dispatched to the memory/cache out of program order, whereas loads may be dispatched to memory/cache anytime no dependencies/conflicts exist between the loads and other store operations.
In some prior art processors, the MOB is used to store load and store operations in proper order, such that all store operations to write information to a memory location are dispatched and allowed to write their information to memory before load operations that may use information from the same address. Store operations appearing in program order before corresponding load operations (i.e. load operations having the same target address as the earlier store operations) may be referred to as “older” store operations and the corresponding load operations may be referred to as “newer” load operations than the earlier store operations in program order.
Loads may access memory out of program order in relation to stores if no dependencies/conflicts between the loads and stores exists. In some of the prior art, loads being processed before older pending stores were assumed to always correspond to the same target memory address in order to prevent the chance that an earlier processed load could load data that was to be updated by the older store, and therefore produce an incorrect result in whatever program they corresponded to by returning obsolete information.
However, this assumption may prove to be too conservative, in as much as not all loads that are processed before older pending stores in program order are processed correspond to the same memory address. As a result, loads may be delayed from being issued to memory for numerous cycles until the corresponding older pending stores are processed and stored in the proper order in the MOB. This can, in turn, cause unnecessary delays in memory access time, which can unduly erode processor and system performance.
The present invention is illustrated by way of example and not limitation in the accompanying figures.
Embodiments of the invention relate to computer systems. More particularly, at least one embodiment of the invention relates to a technique to allow load operations to be issued to memory before older pending store operations. Furthermore, one embodiment of the invention pertains to a technique to disable or enable issuing load operations to memory before older pending store operations depending upon a frequency at which the load and corresponding older store operations do not conflict with each other. Throughout this disclosure, the term “pending” in regard to stores refers to the fact that the target addresses (addresses in memory that the load and store operations are to access) are not yet determined. The term “pending” in regard to loads refers to loads whose target addresses are determined but have yet to be issued to memory/cache.
Instead of always waiting for loads to be processed in program order with respect to pending store operations in the MOB, embodiments of the invention improve the throughput of load accesses to memory by speculating, with/without predicting, whether pending loads (i.e., loads that have yet to be retired) are to load information from memory address not corresponding to any older pending store operation. In at least one embodiment, entries of a load buffer each correspond to a hash predictor array entry, which may maintain a prediction of whether a pending load within a corresponding load buffer entry is to be allowed to access memory ahead of pending older store operations. In one embodiment, the prediction of whether a pending load operation may access memory ahead of a pending older store operation depends upon the success (whether earlier pending loads have accessed memory without conflicting with a older store operation) of prior pending load operations corresponding to a particular predictor table entry.
In one embodiment a saturation counter may be used to maintain a prediction of whether a pending load will conflict (i.e., attempt to access a memory address corresponding to a older pending store operation) with a older pending store operation. If a load that has been allowed to access memory ahead of older pending store operations does ultimately conflict with a older store operation, at least one embodiment restart from the speculative load that caused the conflict. However, at least in one embodiment, a misprediction may occur infrequent enough so as to facilitate an overall improvement in load/store access throughput to memory.
In the event that the success rate of speculative loads accessing memory ahead of older pending store operations fall below a certain threshold, at least one embodiment may include a “watchdog” unit (logic and/or software) to disable pending loads from speculatively accessing memory ahead of older pending store operations. Throughout this disclosure, “memory” may be used to refer to cache, DRAM, or any other memory structure to be accessed by load and store operations.
In one embodiment, loads may be issued to memory/cache before older stores are issued to memory/cache without waiting to determine whether the loads are dependent upon or otherwise conflict with older pending stores. In this manner, at least one embodiment of the invention can improve processor performance due to the fact that loads can be issued without waiting for the target addresses of older stores to be determined, the data from which can be used by the execution unit to dispatch subsequent operations from the scheduler/reservation station sooner than in some prior art architectures.
In one embodiment, a hash table 207 may be used with multiple entries corresponding to loads stored in the load buffer, for example, or loads pending anywhere in the processor. In one embodiment, the hash table is stored in memory, realized in logic circuits, and/or implemented in software. In one embodiment, each entry of the hash prediction table may contain at least one saturation counter to maintain a prediction of whether each load may be issued to memory ahead of older pending store operations pending in the processor. Advantageously, the hash prediction entries may be indexed by an instruction pointer (EIP) or some derivative thereof (e.g., hashed version of EIP).
For example, in one embodiment, each entry may contain a field (MDA field 307) to store bits indicating whether the load is allowed to access memory before pending older store operations, a field (MDD field 309) to indicate whether the corresponding load operation has in fact accessed memory before older pending store operations, a field (MDU field 311) to indicate whether the corresponding load operation should cause the corresponding predictor entry to be updated (based on existence of an older store operation with unresolved address, for example), a field (MDR field 313) to indicate whether the corresponding load should cause the predictor to be reset (in the case of conflict between a load and a store, for example), and a field 315 to store a store color value that indicates the store buffer entry of the youngest store in the store buffer(s) that is older than the load within the particular load buffer entry. Similarly, store buffers within the processor of
Loads stored in the load buffer or other structure may be associated with a predictor table entry, which may implement a hashing function using saturation counters (e.g., 415) in one embodiment to record a history of successful predictions of non-conflicting load and stores. Other prediction techniques may be used in other embodiments.
The prediction table of
In one embodiment, a saturation counter (e.g., 415) corresponding to a load to be issued to memory prior to pending older store operations is incremented or reset to a zero value (or other beginning value) during the load's retirement. In other embodiments, the saturation counter may be modified at other instances. In one embodiment, a saturation counter corresponding to a load that was issued to memory prior to older pending stores is incremented if the load retired without “colliding” (i.e., loading data from a memory address to which the pending older store operation is to write information) with an older store operation that was pending at the time the load was issued. In one embodiment, a saturation counter corresponding to a load to be issued to memory prior to older pending stores is reset if the load collided with an older store operation that was pending when the load was issued (determined, for example, when the load retires).
In one embodiment, a load is issued from one or more processor reservation stations (rather than from the MOB) before pending older store operations if a saturation counter in the predictor table corresponding to that load has reached a threshold value. Otherwise, the load may not be issued from a reservation station, but instead must be issued from the MOB in program order with respect to the older pending stores. In one embodiment, the threshold value of at least one of the saturation counters corresponds to 15 consecutive non-conflicting load issuances, reflected in 15 of the 16 states of the counter, including reset, in one embodiment. In other embodiments, a less-conservative threshold may be chosen, such as 10 consecutive non-conflicting load issuances.
In one embodiment, loads may be scheduled out of order within the scheduler and later sent to the MOB. Loads may then be forwarded from the MOB to be executed immediately (“MOB bypass”) if, for example, there are not previous stores pending, or there are previous stores pending, but the predictor has reached the threshold value. The MOB may alternatively decide that the load cannot continue yet to the execution units (for example, if there are older stores not yet resolved and the correspondent predictor counter is not saturated.) in the cases, the MOB will re-schedule the load later, when the problematic stores are resolved).
In one embodiment, after a saturation counter corresponding to a load of information from a memory address reflects 15 consecutive non-conflicting issuances of loads from that memory address, then subsequent loads may be issued to the memory address out of program order (that is, from the reservation station, via MOB bypass, ahead of older stores), rather than waiting to be issued from the MOB in program order respect to older pending stores. However, in one embodiment, if a load is determined at retirement to have been issued to a memory location in which an older store was to store information (i.e. a conflict between the load and an older store occurs), the saturation counter in the prediction table corresponding to that load (i.e., corresponding the load's EIP) is reset to an initial state, such as a zero value, or decremented to a lesser value, and no further loads from that address may be predicted to be non-conflicted (and therefore be issued to memory before older pending stores to that address) until the saturation counter reaches the threshold value again (e.g., after 15 consecutive non-conflicted loads, in one embodiment). If a load is mispredicted, issued to memory, and is in fact determined to be conflicted with an older store, then the load must be reissued (after performing a pipeline flush/restart operation, for example) from the MOB in program order (i.e. after the older store operations' target addresses have been determined and the stores are stored in program order in the MOB with the loads).
In one embodiment, a saturation counter in the prediction table corresponding to a load to be issued to memory is indexed by the hashed EIP. The result of reading the counter value can be stored in the MDA bit (e.g., “1” for a positive prediction, or “allowed”, “0” for a negative prediction, or “not allowed”) associated with the load, which may be located in a load buffer or the reservation station or some other structure. If the counter value is saturated (i.e., at or above the threshold value), then the load is presumed to not conflict with any older stores that have yet to be issued to memory and the load may be issued to access memory at the targeted address. If the load is later found to conflict with an older store (e.g., after older store target addresses have been determined), then the load is flushed/invalidated and re-issued to memory from the MOB (i.e., in program order with the older stores).
If the predictor is read for a given load and the corresponding counter is not saturated (i.e., contains a value below the threshold), then the load will be stored in the MOB and issued to memory in program order in relation to pending older stores. In one embodiment, MDU bit will be set if the load conflicts with an older store. If the load actually loads information from memory before older pending stores (i.e. load was predicted to not conflict), regardless of whether the load actually conflicts with older stores, then the MDD bit is set. This bit can be consulted to determine whether it is necessary to verify that the prediction was correct. Again, if the prediction was not correct and there was in fact a conflict with an older store, the load will be flushed/invalidated and re-issued along with all following instructions.
In order to detect a misprediction, according to one embodiment, the target addresses of stores older than the load that were resolved after executing the load, are compared with the target address younger loads, including those of the mispredicted load. Once a matching target address of the load and an older store is found, the MDR bit can be set to reflect that the counter for that load must be reset. Furthermore, in one embodiment, an MDD bit can be set to indicate that the mispredicted load is to be flushed/invalidated.
In one embodiment, logic associated with the MOB uses the MDU and MDR bits (stored in a load buffer entry corresponding to the load issued to memory before pending older stores) to determine how the predictor table entry for the predicted/mispredicted load is to be updated. For example, in one embodiment, if the MDU bit is not set, the corresponding saturation counter is not updated, whereas if the MDU bit is set and the MDR bit is not set, the counter is incremented. However, if the MDU and the MDR bits are both set, the counter is reset. The following table summarizes the use of the MDU and MDR bits in determining how or whether to update the predictor table entry for a given load, according to one embodiment:
In one embodiment, the prediction of whether a load to be issued to memory before pending older stores can be temporarily disabled in order to preserve processor performance if the number or rate of mispredictions becomes too high. The prediction technique can then be re-enabled after a certain amount of time or after certain criteria are met. In one embodiment, logic, software, or some combination thereof may be used to implement a “watchdog” unit to control whether the prediction of loads issued to memory before older pending stores is to be enabled or disabled. In one embodiment, the watchdog can be conceptualized as implementing two different states (via a logic state machine, for example), each using two counters to track the success of predictions of any or all loads issued to memory prior to older pending stores.
For example, in one embodiment, when the prediction mechanism described above is enabled, two counters—a disambiguation counter and a flush counter—are used to track the success rate of load predictions. Specifically, a disambiguation counter may increment each time a load is successfully predicted to not conflict with an older pending store operation and therefore loads targeted information from memory without being issued to memory in program order (e.g., from a MOB). On the other hand, a flush counter may decrement each time a load is mispredicted to not conflict with an older pending store operation, which may be determined after the load retires in one embodiment. In addition, the flush counter may be incremented by carry-out values from the disambiguation counter. After the flush counter decrements below zero, thereby creating a negative ratio between the disambiguation counter value and the flushes counter value, then the prediction mechanism is disabled and loads are issued to memory from a MOB in program order with older stores.
The determination of whether to enable the prediction mechanism can also rely on the use of a counter, such as a prediction counter to count the number of successful would-be predictions, and another counter, such as a misprediction counter to count the number of would-be mispredictions. In one embodiment, the prediction counter is incremented after a load is retired that would have otherwise been successfully predicted to not conflict with older pending stores if the prediction mechanism was enabled. The prediction counter is reset to some initial value (e.g., “0”) after a load is retired that would have otherwise been mispredicted to not conflict with older pending stores if the prediction mechanism was enabled, and the mispredictor counter is incremented. After the prediction counter reaches a saturated value (e.g., the maximum count of the counter) and the misprediction counter is not above a maximum threshold, the prediction mechanism for loads can be enabled. The saturated value can depend on when the implementer believes that there will be enough successful load predictions to warrant re-enabling the prediction mechanism. In one embodiment, this may be reflected in a ratio of 256 (corresponding to the predictions counter of 8 bits, for example) would-be successful predictions for every 1 (corresponding to a mispredictions counter of one or more bits, for example) would-be mispredictions.
Similarly, the prediction mechanism may be disabled after a desired ratio of successful to unsuccessful predictions is met. For example, in one embodiment the prediction mechanism is disabled if 4 (corresponding to a 2 bit flush counter, for example) or more mispredictions occurs for every 1024 (corresponding to a 16 bit disambiguation counter, for example) successful predictions. In other embodiments, other techniques may be used to track the success rate of predictions, such as time-dependent counters, in order to determine when to enable or disable the prediction mechanism.
A watchdog unit, such as the one described above can prevent pathological mispredictions of non-conflicting loads from substantially impacting processor performance.
In one embodiment, load buffer entries may also contain storage location to store a memory disambiguation speculation (MDS) bit to indicate whether the corresponding load would have been dispatched to memory ahead of older store operations, but for the watchdog unit being in the disabled state. An MDS bit, or a bit of similar functionality, may assist in determining the “hit rate” of various load operations.
Illustrated within the processor of
The main memory may be implemented in various memory sources, such as dynamic random-access memory (DRAM), a hard disk drive (HDD) 720, or a memory source located remotely from the computer system via network interface 730 containing various storage devices and technologies. The cache memory may be located either within the processor or in close proximity to the processor, such as on the processor's local bus 707.
Furthermore, the cache memory may contain relatively fast memory cells, such as a six-transistor (6T) cell, or other memory cell of approximately equal or faster access speed. The computer system of
The system of
Other embodiments of the invention, however, may exist in other circuits, logic units, or devices within the system of
Processors referred to herein, or any other component designed according to an embodiment of the present invention, may be designed in various stages, from creation to simulation to fabrication. Data representing a design may represent the design in a number of manners. First, as is useful in simulations, the hardware may be represented using a hardware description language or another functional description language. Additionally or alternatively, a circuit level model with logic and/or transistor gates may be produced at some stages of the design process. Furthermore, most designs, at some stage, reach a level where they may be modeled with data representing the physical placement of various devices. In the case where conventional semiconductor fabrication techniques are used, the data representing the device placement model may be the data specifying the presence or absence of various features on different mask layers for masks used to produce an integrated circuit.
In any representation of the design, the data may be stored in any form of a machine-readable medium. An optical or electrical wave modulated or otherwise generated to transmit such information, a memory, or a magnetic or optical storage medium, such as a disc, may be the machine-readable medium. Any of these mediums may “carry” or “indicate” the design, or other information used in an embodiment of the present invention, such as the instructions in an error recovery routine. When an electrical carrier wave indicating or carrying the information is transmitted, to the extent that copying, buffering, or re-transmission of the electrical signal is performed, a new copy is made. Thus, the actions of a communication provider or a network provider may be making copies of an article, e.g., a carrier wave, embodying techniques of the present invention.
Thus, techniques for steering memory accesses, such as loads or stores are disclosed. While certain embodiments have been described, and shown in the accompanying drawings, it is to be understood that such embodiments are merely illustrative of and not restrictive on the broad invention, and that this invention not be limited to the specific constructions and arrangements shown and described, since various other modifications may occur to those ordinarily skilled in the art upon studying this disclosure. In an area of technology such as this, where growth is fast and further advancements are not easily foreseen, the disclosed embodiments may be readily modifiable in arrangement and detail as facilitated by enabling technological advancements without departing from the principles of the present disclosure or the scope of the accompanying claims.
Various aspects of one or more embodiments of the invention may be described, discussed, or otherwise referred to in an advertisement for a processor or computer system in which one or more embodiments of the invention may be used. Such advertisements may include, but are not limited to news print, magazines, billboards, or other paper or otherwise tangible media. In particular, various aspects of one or more embodiments of the invention may be advertised on the internet via websites, “pop-up” advertisements, or other web-based media, whether or not a server hosting the program to generate the website or pop-up is located in the United States of America or its territories.
