JP7064273B2 - Read / store unit with split reorder queue using a single CAM port - Google Patents

Description

Embodiments of the present invention generally relate to out-of-order (OoO) processors, and more specifically, are single to efficiently support out-of-order execution of instructions in the OoO processor. It relates to a load-store unit (LSU) that implements load and store reorder queues divided together with an associative memory (CAM) port.

In the OoO processor, an instruction sequencing unit (ISU) dispatches instructions to various issue queues, renames them in support of OoO execution, issues instructions from the various issue queues to the execution pipeline, and issues them to the execution pipeline. Complete the executed instruction and handle the exception condition. Register renaming is usually performed by mapper logic in the ISU before the instruction is placed on each issue queue. The ISU contains one or more issue queues containing a dependency matrix for tracking dependencies between instructions. The dependency matrix typically contains one row and one column for each instruction in the issue queue.

Provides a read / store unit with a split reordering queue that uses a single CAM port.

Embodiments of the invention include methods, systems, and computer program products for implementing effective address-based read / store units in out-of-order processors. A non-limiting example of a processing unit for executing one or more instructions is a read / store unit (LSU), where the LSU is out of order (OoO) using multiple LSU pipes. Execute multiple instructions in a window. This execution is to select an instruction from the OoO window, where the processing unit operates in single-threaded mode in response to the instruction using the effective address, the selection, and the instruction being a read instruction. Creating an entry in the first partition of the read order change queue based on the fact that the instruction was issued on the first read pipe in response to the instruction and the instruction on the second read pipe. Includes creating an entry in the second partition of the read order change queue based on being issued in. This execution is based on the fact that the instruction is issued on the first read pipe in response to the processing unit operating in a multithreaded mode where multiple threads are processed simultaneously. It also includes creating an entry in the first predetermined part of the first partition of the read order change queue by the first thread.

According to one or more embodiments, the computer implementation method for out-of-order execution of one or more instructions by a processing unit is out of order by the processing unit read / store unit (LSU). It involves receiving an out-of-order window of an instruction containing multiple instructions to be executed and issuing the instruction from the OoO window by the LSU. Issuing an instruction is to select an instruction from the OoO window, where the processing unit is in single-threaded mode in response to the instruction using the effective address, the selection, and the instruction being a read instruction. Creating an entry in the first partition of the read order change queue based on the fact that the instruction was issued on the first read pipe in response to the operation, and the instruction on the second read pipe. Includes creating an entry in the second partition of the read order change queue based on being issued above. This execution is based on the fact that the instruction is issued on the first read pipe in response to the processing unit operating in a multithreaded mode where multiple threads are processed simultaneously. It also includes creating an entry in the first predetermined part of the first partition of the read order change queue by the first thread.

According to one or more embodiments, the computer program product comprises a computer-readable storage medium in which the program instructions are embodied, the program instructions being used to cause the processing unit to perform an operation. It is feasible by. Their operation is to receive an out-of-order window of instructions containing multiple instructions executed out of order by the processing unit's read / store unit (LSU), and by LSU, the OoO window. Includes issuing orders from. Issuing an instruction is to select an instruction from the OoO window, where the processing unit is in single-threaded mode in response to the instruction using the effective address, the selection, and the instruction being a read instruction. Creating an entry in the first partition of the read order change queue based on the fact that the instruction was issued on the first read pipe in response to the operation, and the instruction on the second read pipe. Includes creating an entry in the second partition of the read order change queue based on being issued above. This execution is based on the fact that the instruction is issued on the first read pipe in response to the processing unit operating in a multithreaded mode where multiple threads are processed simultaneously. It also includes creating an entry in the first predetermined part of the first partition of the read order change queue by the first thread.

Other features and advantages are realized by the method of the present invention. Other embodiments and aspects of the invention are described in detail herein and are considered part of the claimed invention. Please refer to the description and drawings for a good understanding of the invention along with its advantages and features.

The details of the possession rights described herein are specifically pointed out and explicitly claimed within the scope of the claims at the end of the specification. The aforementioned and other features and advantages of each embodiment of the invention will be apparent from the following detailed description provided with the accompanying drawings.

FIG. 3 is a block diagram of a system comprising an effective address-based read / store unit within an out-of-order processor according to one or more embodiments of the present invention. An exemplary block diagram of a processor architecture of an OoO processor that implements an effective address directory (EAD) and related mechanisms for utilizing this EAD, according to one or more embodiments of the invention. Is. It is a figure which shows the reading / storing unit (LSU) of the processing core according to one or more embodiments of this invention. It is an exemplary block of an effective address directory (EAD) structure (L1 cache) according to one embodiment. It is an exemplary block of an effective real translation (ERT) table structure according to one embodiment. It is a flowchart of an exemplary method for accessing memory to execute an instruction by LSU, according to one or more embodiments of the present invention. It is a flowchart of the method for reloading ERT according to one or more embodiments of this invention. It is a figure which shows the exemplary structure of the synonym detection table (SDT) according to one or more embodiments of this invention. It is a flowchart of the method for performing exchange of ERT and SDT EA according to one or more embodiments of this invention. FIG. 5 shows an ERTeviction (ERTE) table according to one or more embodiments of the present invention. It is a flowchart of an exemplary method for adding an entry to an ERTE table according to one or more embodiments of the present invention. It is an exemplary sequence diagram of a set of exemplary instructions initiated according to one or more embodiments of the invention. In multipipe mode, depending on whether the processor is operating in singlethread (ST) mode or multi-threaded (MT) mode, according to one or more embodiments of the invention. And in the OoO method, it is a flowchart of an exemplary method for issuing an instruction by LSU. FIG. 3 is a block diagram of a computer system for implementing some or all embodiments of one or more embodiments of the present invention.

The figures shown herein are examples. It is possible that many variations of the figures or behaviors described herein exist without departing from the ideas of the present invention. For example, actions can be performed in different order, or actions can be added, deleted, or modified. Also, the term "combined" and its variants represent the existence of a communication path between two elements, meaning a direct connection between elements without element / connection intervening between those elements. Not. All these variations are deemed to be part of this specification.

One or more embodiments of the invention described herein are read / store units based on an effective address (EA) by dynamically deleting entries in an effective real address table within an OoO processor. (LSU) is provided to the out-of-order (OoO) processor. The technical solutions described herein are effective real tables (ERTs), among other components, to facilitate chip area reductions and, in addition, to improve the timing of OoO processors. ) And the synonym detection table (SDT) and the effective address directory (EAD) are used. In addition, the technical solutions described herein facilitate the OoO LSU to execute read / store instructions in an unordered manner. OoO LSU uses multiple pipes to execute read / store instructions to improve performance. LSU's multi-pipe implementation is based on split ERTs, load reorder queues (LRQs), and store reorder queues (SRQs), as described herein.

Most modern computing devices support virtual memory. Virtual memory gives application programs the impression that continuous working memory or address space exists even when physical memory is actually fragmented and when physical memory is flooded with disk storage. It is a technique to give. Basically, the memory appearance of the computing device is provided to the application program, and the application uses the effective addresses in the effective address space visible to the application to access the continuously visible memory and then. This effective address is translated into the physical address of the actual physical memory or storage device in order to actually perform the access operation. The effective address is a value used to specify the memory location accessed by the operation from the perspective of the entity issuing the operation (eg, application, process, thread, interrupt handler, kernel component, etc.).

That is, if the computing device does not support the concept of virtual memory, then there is one effective address and one physical address, which is the same. However, if the computing device supports virtual memory, the effective address of the particular operation submitted by the application is the physical memory or storage device on which the operation is performed by the memory mapping unit of the computing device. Translated to a physical address that specifies a location within.

In addition, in modern computing devices, the processor of the computing device is an instruction submitted by an entity (eg, application, process, etc.) using a processor instruction pipeline that contains a set of data processing elements. Process (operation). Instruction pipeline is a technique that increases instruction throughput by dividing the processing of computer instructions into a series of steps that use storage at the end of each step. The instruction pipeline makes it easy for the control circuit of the computing device to issue instructions to the processor instruction pipeline at the slowest step speed, which is required to execute all steps simultaneously. It's much faster than the time. Processors that use instruction pipelines (ie, pipelined processors) are internally structured in stages that can operate semi-independently for separate jobs. Each stage is structured so that the output of each stage is supplied to another stage up to the last stage of the pipeline, and is connected to the next stage in a series of chains.

Such pipeline processors may take the form of in-order pipeline processors or out-of-order pipeline processors. For in-order pipeline processors, if data is not used for instructions processed at a particular stage in the pipeline, execution of instructions through the pipeline is stopped until the data is available. The instructions are executed in order. Out-of-order pipeline processors, on the other hand, allow processors to avoid outages that occur when the data needed to perform an operation is unavailable. The out-of-order processor instruction pipeline fills a "slot" of time with other instructions that are ready to be processed, then sorts the results at the end of the pipeline, and the instructions are executed in order. Prevent them from stopping by making them look like they are. The way instructions are ordered in the original computer code is called program order, while the processor processes the instructions in data order (that is, the order in which data and operands are available in the processor's registers). ..

Modern processor instruction pipelines track the effective address of an instruction as it flows through the instruction pipeline. Whenever the processing of an instruction results in getting an exception, the instruction flushes the previous state, the instruction branches to a new memory location relative to the current memory location, or the instruction execution completes. Since this effective address is used, it is important to keep track of the effective address of the instruction.

Tracking the effective address of an instruction is costly in terms of processor chip area, power consumption, and so on. This is because these effective addresses have a large size (eg, 64 bits), the modern processor instruction pipeline is deep (ie, contains many stages), and the instruction fetch stage of the processor instruction pipeline. This is because it causes the instruction to have a very long duration from to the completion stage of the processor instruction pipeline. A highly multithreaded out-of-order processor (ie, a processor that executes instructions from multiple threads in an unordered manner) can process a huge number of instructions from different address ranges simultaneously. This cost may be further increased because it is (ie, "in-flight").

In one or more examples, the computing device uses a combination of pipeline latches, branch information queues (BIQs), and global completion tables (GCTs) for instructions. Track the effective address. The base effective address (EA) of a group of instructions is forwarded from the front end of the pipeline using a latch until it can be stored and tracked in the GCT of the instruction sequencer unit (ISU). .. The number of latches required to store this data is approximately the number of stages in the pipeline between the fetch and dispatch stages of the pipeline. These latches are useless as they usually do not require an EA between these stages. This data is just payload data that "associates" with the instruction group as the instruction flows through the pipeline. In addition, this method leads to double storage because the branch instruction includes EA in both BIQ and GCT.

Therefore, computing devices have been developed that eliminate such inefficiencies by tracking the EA only in the GCT. For example, those new computing devices (instruction sequencer units) create entries in the GCT on fetch. The EA is read into the GCT at this point and then deleted when the instruction is completed. This removes many pipeline latches throughout the device. Instead of a full EA (eg, 64-bit EA) as long as the number of address lines, a small tag is carried with the instruction group through the pipeline. This tag points to an entry in the GCT that holds the base EA of this instruction group. When the branch is issued, the EA can be obtained directly from the GCT, eliminating the need to store the address in the BIQ. Such techniques improve area efficiency, but are not applicable to out-of-order processors. Moreover, those techniques lack sufficient information to process incoming address requests out of program order. In addition, these techniques lack the ability to track instruction groups that may be formed from multiple disjointed address ranges, thus supporting the dispatch and completion bandwidth required for out-of-order execution. Can not. Traditionally, such a mechanism has supported only instruction groups from a single address range, which can significantly reduce the number of instructions that can be used to execute out of order. In addition, associative memory (CAM: content addressable memory) is used to retrieve the corresponding address, such as RA corresponding to EA (or vice versa). CAM implements a look-up table function in a single clock cycle using a dedicated comparison circuit. The entire function of CAM is to receive a search term and return a matching memory location. However, such a CAM requires chip area and consumes power for such a search.

The embodiments of the technical solutions described herein not only have the area efficiency of the GCT solutions described above, but also support a wide out-of-order pipeline without compromising performance. These techniques are improved by providing an effective address directory (EAD), an effective real table (ERT), and a synonym detection table (SDT) that can be used. The technical solutions described herein make it even easier for the processor to run using EA alone, as long as the processor can avoid EA synonyms within the out-of-order (OoO) window. .. An OoO window is a set of instructions in a processor's instruction pipeline. By preventing the synonyms of the EA in the OOO window, the processor can avoid the translation of the EA in the OOO window, so that the processor reduces the chip area and power consumption for address translation. This is because the EA synonym no longer exists in the OoO window, and the load hit store (LHS: load-hit-store) condition, store hit load (SHL: store-hit-load) for in-flight instructions. ) Condition and load-hit-load (LHL: load-hit-load) condition are no longer detected.

In other words, the technical solutions described herein address technical issues by restricting EA aliasing in OoO windows and reducing the conversion data structure and hardware for read / store ports. do. Therefore, the technical solutions described herein facilitate chip area reduction by tracking only one address (EA). In addition, these technical solutions make it easy for the OoO processor to perform in 2 load and 2 store modes with split load and store queues, usually address translation. Further reduce the number of CAM ports used for.

In addition, if the OoO processor supports multithreaded (MT) operation, the OoO processor will convert EA to RA and RA to EA for each thread operation in an unordered manner. Multiple CAM ports need to be facilitated for each read / store queue in the read / store unit. For example, consider an OoO processor that runs four threads in MT mode. Each thread is executing at the same time by executing independent instructions. In this case, the OoO processor's read / store unit (LSU) typically has four or more CAM ports per read / store queue to translate the effective address to the real address and to translate the real address to the effective address. To use. Such multiple CAM ports for address translation occupy a considerable chip area and consume more power. The technical solutions described herein address such technical challenges of multiple CAM ports for multiple threads.

One or more embodiments of the invention described herein address aspects of the technical challenges described herein by using a single CAM port for read / store queues. In this way, the chip area and power used for address translation is reduced. For example, an embodiment of the invention described herein facilitates an LSU to be a multi-load and multi-store LSU (multi-load and multi-store LSU) that includes a split load / store queue. Can help reduce the number of CAM ports for address translation. "Multiple read LSUs" are LSUs that simultaneously issue a plurality of read instructions on separate pipes for each read instruction. For example, "2 read LSUs" are LSUs that issue two read instructions simultaneously on two separate pipes (LD0 and LD1). Similarly, the "plural storage LSU" is an LSU that simultaneously issues a plurality of storage instructions on separate pipes for each storage instruction. For example, "2 storage LSUs" are LSUs that simultaneously issue two storage instructions on two separate pipes (ST0 and ST1).

Referring now to FIG. 1, an out-of-order (OoO) processor instruction ordering unit that implements a technical solution to prevent EA synonyms within the OoO instruction window according to one or more embodiments of the invention. A block diagram of the system 100 containing (ISU) is generally shown. System 100, shown in FIG. 1, prepares a decoded instruction for input to the ISU mapper 110. An instruction fetch unit / instruction decode that fetches and decodes an instruction for input to the configuration block 108. -The unit (IFU / IDU: instruction fetch unit / instruction decode unit) 106 is included. According to one or more embodiments of the invention, the IFU / IDU 106 may fetch and decode six instructions from a thread at a time. According to one or more embodiments of the invention, the six instructions transmitted to the configuration block 108 are six non-branch instructions, five non-branch instructions and one branch instruction, or four non-branch instructions and two. Can include branch instructions. According to one or more embodiments of the invention, the configuration block 108 includes entries in the issue queue, completion tables, mappers, register files, etc. before sending the fetched instructions to those blocks in the ISU. Check that there are enough resources for.

The mapper 110 shown in FIG. 1 maps programmer instructions (eg, logical register names) to processor physical resources (eg, physical register addresses). In FIG. 1, a condition register (CR) mapper, a link / count (LNK / CNT: link / count) register mapper, an integer exception register (XER) mapper, and general purpose registers (GPR) are shown. And an integrated mapper (UMapper) for mapping vector-scalar registers (VSRs), a pre-designed mapper (ARCH mapper) for mapping GPRs and VSRs, and floating point numbers. Various mappers 110 are shown, including a floating point status and control register (FPSCR) mapper.

The output from the configuration block 108 is also input to the global completion table (GCT) 112 for tracking all instructions in the current ISU. The output from the configuration block 108 is also input to the dispatch unit 114 for dispatching instructions to the issue queue. The ISU embodiment shown in FIG. 1 includes a CR issue queue (CR ISQ: CR issue queue) 116, which receives and tracks instructions from the CR mapper and tracks them. The instruction is issued (120) to the instruction fetch unit (IFU) 124 to execute the CR logical instruction and the move instruction. FIG. 1 also shows a branch issue queue (branch issue queue) 118, which receives and tracks branch instructions and LNK / CNT physical addresses from the LNK / CNT mapper. The branch ISQ118 may issue an instruction to the IFU 124 to redirect the instruction fetch if the predicted branch address and / or direction is incorrect.

Instructions output from the dispatch logic and the registers renamed from the LNK / CNT mapper, the XER mapper, the UMapper (GPR / VSR), the ARCH mapper (GPR / VSR), and the FPSCR mapper are input to the issue queue 102. .. As shown in FIG. 1, the issue queue 102 contains dispatched fixed point instructions (Fx), load instructions (L), store instructions (S), and vectors and scalars. -Track unit (VSU: vector-and-scaler unit) instructions. As shown in the embodiment of FIG. 1, the issue queue 102 is divided into two parts ISQ0 1020 and ISQ1 1021, each part holding N / 2 instructions. When the processor is running in single thread (ST) mode, the issue queue 102 has ISQ0 1020 and ISQ1 1021 to process all instructions in a single thread (in this example, all N instructions). Can be used as a single logical issue queue containing both.

When the processor is running in multithreaded (MT) mode, ISQ0 1020 can be used to process N / 2 instructions from the first thread and ISQ1 1021 is the second thread ISQ1. Used to process N / 2 instructions from 1021.

As shown in FIG. 1, the issue queue 102 issues an instruction to the execution unit 104, which is divided into two groups of execution units (1040 and 1041). Both groups (1040 and 1041) of execution units shown in FIG. 1 are full fixed point execution units (full FX0, full FX1), read execution units (LU0, LU1), simplified. Fixed-point, stored data, and stored address execution units (simple FX0 / STD0 / STA0, simple FX1 / STD1 / STA1), and floating point, vector multimedia execution, decimal floating point, and stored data execution units (FP / VMX / DFP / STD0, FP / VMX / DFP / STD1) is included. LU0, simplified FX0 / STD0 / STA0, and FP / VMX / DFP / STD0 collectively form a read / store unit (LSU) 1042. Similarly, LU1, Simplified FX1 / STD1 / STA1, and FP / VMX / DFP / STD1 form a read / store unit (LSU) 1043. The two LSUs 1042 and 1043 are collectively referred to as the LSU of system 100.

As shown in FIG. 1, when the processor is running in ST mode, the first group 1040 of the execution units executes the instructions issued by ISQ0 1020 and the second group 1041 of the execution units. Executes the instruction issued by ISQ1 1021. In an alternative embodiment of the invention when the processor is running in ST mode, instructions issued by both ISQ0 1020 and ISQ1 1021 in the issue queue 102 are the first group 1040 of the execution unit and the execution unit. Can be issued to an execution unit included in any of the execution units 1040 in the second group 1041 of.

According to one or more embodiments of the present invention, when the processor is running in MT mode, the first group 1040 of execution units executes and executes the instructions of the first thread issued by ISQ0 1020. The second group 1041 of the unit executes the instruction of the second thread issued from ISQ1 1021.

Since embodiments of the present invention can be implemented with respect to various different sizes of issue queues and other elements, the number of entries in the issue queue 102 and the size of the other elements shown in FIG. 1 (eg, bus width). , Cue size) is intended to be exemplary in practice. The size is selectable or programmable according to one or more embodiments of the invention.

In one or more examples, the system 100 is an OoO processor according to an embodiment. FIG. 2 is an exemplary block of the processor architecture of an OoO processor that implements an effective address directory (EAD) and related mechanisms for utilizing this EAD, according to one or more embodiments of the invention. It is a figure. As shown in FIG. 2, this processor architecture includes an instruction cache 202, an instruction fetch buffer 204, an instruction decode unit 206, and an instruction dispatch unit 208. The instruction is fetched from the instruction cache 202 by the instruction fetch buffer 204 and provided to the instruction decoding unit 206. The instruction decoding unit 206 decodes the instruction and provides the decoded instruction to the instruction dispatch unit 208. The output of the instruction dispatch unit 208, depending on the type of instruction, is the global completion table 210, as well as the branch issue queue 212, the condition register issue queue 214, the unified issue queue 216, the read order change queue 218, or It is provided to one or more of the storage order change queue 220 or a combination thereof. The type of instruction is determined by the decoding and mapping of the instruction decoding unit 206. Issue queues 212-220 provide inputs to various execution units of execution units 222-240. The data cache 250 and the register files included with each unit provide data for use in the instruction.

The instruction cache 202 receives instructions from the L2 cache 260 via the second level conversion unit 262 and predecode unit 270. The second level translation unit 262 uses the associate segment look-aside buffer 264 and the translation lookaside buffer 266 to address the fetched instructions as the effective address. To the system memory address. The pre-decoding unit partially decodes the incoming instructions from the L2 cache and expands those instructions with unique identification information, simplifying the work of the downstream instruction decoder.

The instruction fetched in the instruction fetch buffer 204 is also provided to the branch prediction unit 280 if the instruction is a branch instruction. The branch prediction unit 280 includes a branch history table 282, a return stack 284, and a count cache 286. These factors then predict the effective address (EA) to be fetched from the instruction cache. A branch instruction is a position in a computer program where the flow of control is changed. A branch instruction is a low-level machine instruction generated from a control structure in a computer program, such as an if-then-else statement or a do-while statement. A branch may not be selected, in which case the flow of control does not change and the next instruction executed may be the instruction immediately following that branch in memory, or a branch may be selected, in which case. , The next instruction to be executed is an instruction somewhere else in memory. If a branch is selected, a new EA needs to be presented in the instruction cache.

The EA and related prediction information from the branch prediction unit is written to the effective address directory 290. Later, this EA is confirmed by the branch execution unit 222. If this EA is correct, it will remain in the directory until all instructions from this address area have completed execution. If this EA is incorrect, the branch execution unit flushes the address and the corrected address is written to that location. The EAD290 also includes a logical unit that facilitates the use of the directory as a CAM.

An instruction to read from the memory or an instruction to write to the memory (such as a read instruction or a storage instruction) is issued to the LS / EX execution units 238 and 240. The LS / EX execution unit retrieves data from the data cache 250 using the memory address specified by the instruction. This address is an effective address and must first be translated into a system memory address via a second level translation unit before it can be used. If the address is not found in the data cache, a load miss queue is used to manage the failed requests for the L2 cache. To reduce the disadvantages of such cache misses, advanced data prefetch engines predict addresses that are likely to be used by instructions in the near future. In this way, when an instruction requires data, it is more likely that the data already exists in the data cache, thereby preventing long wait times for failed requests for the L2 cache.

The LS / EX execution units 238 and 240 execute instructions out of program order by tracking the age and memory dependencies of the instructions in the read order change queue 218 and the storage order change queue 220. These queues are used to detect when an out-of-order execution produces a result that does not match the in-order execution of the same program. In such a case, the current program flow is flushed and re-executed.

The processor architecture further includes an effective address directory (EAD) 290, which provides an effective address when an effective address is required but does not need to go through the pipeline. Maintain the effective address of a group of instructions in a centralized way so that it can be used. In addition, the EAD290 includes circuits and / or logic to support out-of-order processing. FIG. 2 shows the EAD290 being accessed via the branch prediction unit 280, but various units of the units shown in FIG. 2 can access the EAD290 without having to go through the branch prediction unit 280. It should be understood that a circuit for doing so may be provided.

Those skilled in the art will appreciate that the hardware of FIGS. 1-2 may vary depending on the implementation. Other internal hardware or peripherals, such as flash memory, equivalent non-volatile memory, or optical disk drives, may be in addition to or in place of the hardware shown in Figures 1-2. , May be used. In addition, the process of the examples may be applied to a multiprocessor data processing system other than the SMP system described above without departing from the idea and scope of the present invention.

In addition, the data processing system 100 includes client computing devices, server computing devices, tablet computers, laptop computers, telephones or other communication devices, personal digital assistants (PDAs). It may take any form of a plurality of different data processing systems, including. In some examples, the data processing system 100 is configured with flash memory to provide non-volatile memory, for example to store operating system files and / or user-generated data. It may be a non-volatile computing device. Basically, the data processing system 100 may be any known data processing system or a data processing system developed later, without architectural restrictions.

As will be appreciated by those skilled in the art, the invention may be embodied as a system, device, or method. In one embodiment, the mechanism is provided entirely in hardware (eg, processor circuits, hardware modules, or units, etc.). However, in other embodiments, a combination of software and hardware may be utilized to provide or implement the features and mechanisms of the embodiments. For example, the software may be provided in firmware, resident software, microcode, and the like. The various flowcharts shown below provide an overview of the actions that may be performed by hardware, or a combination of hardware and software, or both.

In embodiments where the mechanisms of the embodiments are implemented, at least in part, in software, any combination of one or more computer-enabled or computer-readable media containing the software may be utilized. For example, a computer-enabled or computer-readable medium may be, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or device. More specific examples of computer-readable media (non-exhaustive list) include random access memory (RAM), read-only memory (ROM), and erasable programmable read-only memory (EPROM). : Erasableprogrammable read-only memory or flash memory).

Normally, all read and store instructions are converted by the EA to the corresponding RA. Such an EA to RA conversion is also performed in the case of instruction fetch (I-fetch). In the case of retrieving instructions from low-order memory, such a translation usually required an effective to real address table (EART). In the technical solution described herein, the EA to RA conversion is not performed for all read and store instructions, but for read failures, I-fetch failures, and all stores. Will only be executed.

These technical solutions use only EA for operation and RA bits (eg, bits) from one or more data structures such as EA directory (also called L1 directory), LRQF entry, LMQ entry, etc. 8:51) facilitates removal. Furthermore, if only EA is used, the SRQ LHS RA comparison logic is not executed. By removing such elements, the chip area of the processor used is reduced, thus facilitating a reduction in chip area beyond that of a normal processor.

Further, the technical solution herein eliminates the ELAT search on generation of all read and store addresses by using only the EA. These technical solutions further eliminate RA bus switching across the unit and also avoid high speed SRQ LHS RA cams. Therefore, these technical solutions facilitate the processor to consume less power compared to a normal processor by not performing the above operation.

In addition, the technical solutions herein also facilitate improvements in L1 latency. For example, the technical solution herein is to determine the "final dval" by removal, where the address translation is at least one cycle compared to a normal processor performing an EA to RA translation. It will be faster. By using only the EA (without RA conversion), the waiting time is also improved because "bad dval" conditions such as multiple hits in the setting table and hits / RA failures in the setting table are eliminated. In a similar manner, the technical solutions herein facilitate improvements in L2 latency.

The technical challenges of using only EA-based LSUs include being able to handle snoops from L2. For example, the LSU needs to be able to include an inverse transformation from RA to EA. Therefore, the technical solution herein facilitates the conversion of RA-based snoops from L2 into EA-based snoops to subunits of LSU.

In addition, EA-only LSUs have the technical challenge of handling synonyms for the same thread (ie, two different EA's from one thread are mapped to the same RA). These technical solutions address such technical challenges using either the synonym detection table (SDT) or the ERT deletion (ERTE) table described herein. For example, access to L1 across LHS, SHL, and LHL when the synonym is defined as:
Tid = w, EA (0:51) = x => RA (8:51) = z
Tid = w, EA (0:51) = y => RA (8:51) = z
In this way, different EA's correspond to the same RA. The technical solutions described herein facilitate the rejection of EA synonyms and resumption with the corresponding primary EA.

Referring again to the figure, FIG. 3 shows a processing core read / store unit (LSU) 104 according to one or more embodiments of the present invention. It should be noted that the LSU 104 shown facilitates execution in 2 read / 2 store modes, but the technical solutions described herein are not limited to such LSUs. .. In the following, the flow of execution of LSU will be described. An EA (effective address used by a programmer in a computer program) is generated from a read or store instruction. Similarly, an EA is generated in the case of instruction fetch. Normally, for every instruction, the EA is converted to RA (the real address used by the hardware after the conversion from EA to RA), which requires a larger chip area and frequent conversions, among other technical challenges. rice field. The technical solution described herein uses only EA (without conversion to RA) and is an effective real table (ERT) only on read failure, I-fetch failure, and storage. Such technical challenges are addressed by using 255 to generate RA.

The LSU 104 includes a read order change queue (LRQF) 218, which tracks all read operations from dispatch to completion, similar to the LRQ218 in a normal LSU design. The LSU 104 further includes a second read order change queue LRQE225. If a read is rejected (because of a cache miss or conversion failure, or because an instruction before the read depends on it is rejected), the read is taken from the issue queue, placed in the RQE entry, and read from this RQE entry. Will be reissued. The LRQE225 shown is divided into two instances (LRQE0 and LRQE1) for two read modes, each containing 12 entries (24 entries in total). In ST mode, there is no thread / pipe based partition. In the MT mode, the operations of T0 and T2 are started by the pipe LD0, and the operations of T1 and T3 are started by the pipe LD1 for restarting. Here, Tx is thread x, for example, T0 is thread 0, T1 is thread 1, T2 is thread 2, and T3 is thread 3. In this specification, each example uses four threads in MT mode, but in other examples, different numbers of threads in MT mode (such as 8, 16, or any other number) can be executed simultaneously. It should be noted that it may be included. In one or more examples, the number of threads in MT mode is configurable. Further, in the examples herein, the LSU 104 uses two read pipes (LD0 and LD1), but in other examples the number of pipes may be different (eg, 3, 4, 8 etc.). .. In one or more examples, the LRQF218 is divided into as many partitions as there are pipes.

As shown, the LRQF218 is split into two instances (LRQF0 and LRQF1) for two read modes, containing 40 entries (per instance). LRQF218 is the allocation of circularly ordered entries, the ejection of circularly ordered entries, and the unallocation of circularly ordered entries. Further, in the MT mode, the operations of T0 and T2 are started in the pipes LD0 and ST0, and the operations of T1 and T3 are started in the pipes LD1 and ST1. In ST mode, the LRQF does not contain any pipes / threads.

In one or more examples, in SMT4 mode, the LRQF218 (and other structures described herein) is a T0: LRQF0 [0:19] circular queue, a T1: LRQF1 [0:19] circular queue. , And T2: LRQF0 [20:39] circular queue, and T3: LRQF1 [20:39] circular queue.

In one or more examples, in SMT2 mode, the LRQF218 (and other structures described herein) is a T: LRQF0 [0:39] circular queue and a T1: LRQF1 [0:39] circular queue. Is divided as. Further, in one or more examples, in ST mode, it is an LRQF0 [0:39] circular queue, where LRQF1 is a copy of LRQF0. For other data structures, a similar partition pattern is used in ST mode, where the second instance is the first instance copy.

In the case of a cross invalidation flush (XI flush), for LRQF, NTC + 1 flushes the thread that hits the XI or storage discharge from another thread, and in the case of the XI flush, the explicit L at the time of synchronization. Prevents / L ordering flushes from being performed by LSU104.

All stores check against LRQF218 for SHL detection, and upon detection of SHL, LRQF218 initiates a read after storage or a flush of everything (instructions / actions). In addition, the DCB instruction checks against the LRQF218 for the SHL case, and when the SHL case occurs, the LRQF218 triggers a read after the DCB or a flush of everything. In addition, all reads check against LRQF218 for LHL detection (sequential read consistency), and upon detection of LHL, LRQF218 triggers newer reads or flushes of everything after older reads. In one or more examples, the LRQF218 provides the atomicity of the quad word, the LQ checks against the LRQF218 for the atomicity of the quad, and flushes the LQ if it is not atomic. Further, in the case of a LARX instruction, the LSU 104 checks against the LRQF218 for the case of a larx hit larx and accordingly flushes the newer LARX or everything after the older larx instruction.

In this way, the LRQF218 facilitates tracking of all read operations from issue to completion. The entries in LRQF218 are indexed by Real_Ltag (rltag), which is a physical location in the queue structure. Read operation / entry age in LRQF218 is determined using the ordered Visual_Ltag (vltag). LRQF flashes reads using GMASK, and some groups flash using GTAG and IMASK. LRQF logic can be flushed from the current i-tag or i-tag + 1 or the exact read i-tag.

In addition, the LRQF does not include the commonly used RA (8:51) field, but instead is based on the EA and includes the ERT ID (0: 6) and EA (40:51) (24-bit savings). Matching LRQF pages in SHL, LHL is based on matching ERT IDs. In addition, each LRQ entry contains a "Force Page Match" bit. If the ERT ID that matches the ERT ID of the LRQ entry is invalidated, the page match coercion bit is set. LRQ detects LHL, SHL and flushes including the entry whose storage order is page match forced = 1.

In this way, the LRQF218 addresses the technical challenges of multiple CAM ports that occupy chip area and consume power for address translation by maintaining a split read request queue. It is divided for a given number of instructions and a given number of threads that the OoO processor can execute at the same time.

The SRQ220 of the LSU 104 has a structure similar to the LRQF218, including two instances SRQR0 and SRQR1 with 40 entries (per instance), where SRQR0 and SRQR1 assign entries in a circular order, in a circular order. Ejection of entries, and deallocation of entries in a circular order. Further, the SRQ220 is divided in the same manner as the LRQF218 (for example, the operation of T0 and T2 started on the pipes LD0 and ST0, the operation of the T1 and T3 started on the pipes LD1 and ST1, and the pipe / in ST mode. There is no thread partition). In ST mode, both copies contain the same value, and in MT mode, each copy is different. In SMT4 mode, both instances are further subdivided and each thread is assigned 20 entries from SRQ220 (see the exemplary partition of LRQF described herein). In one or more examples, in the case of store drain arbitration, the SMT4 mode performs multiplexing of read pointers in the SRQ. As an alternative or addition, multiplexing between SRQ0 / 1 is performed in SMT2 and SMT4 modes. In the ST mode, the discharge is executed only for SRQ0.

Here, Tx is thread x, for example, T0 is thread 0, T1 is thread 1, T2 is thread 2, and T3 is thread 3. In this specification, each example uses four threads in MT mode, but in other examples, different numbers of threads in MT mode (such as 8, 16, or any other number) can be executed simultaneously. It should be noted that it may be included. In one or more examples, the number of threads in MT mode is configurable. Further, in the examples herein, the LSU 104 uses two storage pipes (ST0 and ST1), but in other examples the number of storage pipes may be different (eg, 3, 4, 8 etc.). ). In one or more examples, the SRQR 220 is divided into as many partitions as there are storage pipes.

Each entry in the SRQ 220 contains a storage TID (0: 1), ERT ID (0: 6), EA (44:63), and RA (8:51). To detect LHS, LSU uses {stored Tid, EA (44:63)} and thus removes the RA LHS alias check. The ERT ID is used to "catch" the speculative failure of the EA (44:63) partial match. The SQR entry contains RA (8:51), which is converted again on storage and is used only when the storage request is sent to L2 (the storage instruction is ejected and not issued). Each SRQ entry also contains a "force page match" bit. The page match coercion bit is set when the ERT ID that matches the ERT ID of the SRQ entry is invalidated. The SRQ can detect LHS with an entry for which page match coercion = 1. For example, an LHS contrary to an entry for which page match compulsion = 1 causes the read instruction to be rejected. Further, the storage discharge forces a failure in the L1 cache when page match coercion = 1 for the SQR entry. This works in parallel with the "Extended store hit reload" LMQ operation.

For example, in the case of LMQ, LMQ address match = {ERT ID, EA page offset (xx: 51), EA (52:56)} match. Further, the "page match enforcement" bit of each LMQ entry is set when the ERT ID matching the ERT ID of the LMQ entry is invalidated (= 1). The LMQ rejects the read failure if the page match forcible = 1 of the valid LMQ entry [x] and the EA [52:56] of the read failure = the EA (52:56) of the LMQ entry [X]. In addition, LMQ includes extended store hit reloads. For example, the LMQ enables reloading when reloading EA (52:56) = EA (52:56) for SRQ entry [X] and page match enforcement = 1 for SRQ entry [X]. Suppress. As an alternative or addition, the LMQ will enable reloading if the EA (52:56) for the LMQ entry [X] = EA (52:56) for the store and discharge and page match enforcement for the store and discharge = 1. Suppress.

The LSU 104 shown collapses the Store Data Queue (SDQ) as part of the SRQ220 itself to further save chip area. If the size of the operand is smaller than the size of the SRQ entry (eg, 8 bytes), the operand is stored in the entry of the SRQ itself. For wider operands (eg, 16 bytes wide), such as vector operands, in MT mode, the SRQ stores those operands using two consecutive entries in the SRQ220. In ST mode, wider operands are stored in SRQ0 and SRQ1 (eg, 8 bytes each).

The SRQ220 queues storage, barrier, DCB, ICBI, or TLB type operations. A single s tag is used for both story_agen and story_data. The SRQ220 handles load hit store (LHS) cases (same threads only). For example, all reads issued are checked by SRQ220 to ensure that there are no old stores with data conflicts. Data conflicts are detected, for example, by comparing the read EA and data byte flags against the old stores in the SRQ EA array.

SRQ entries are assigned by dispatch, and the dispatched instruction tags (i-tags: instructiontags) are entered in the correct line. Further, the SRQ entry is deallocated when the storage / discharge occurs. In one or more examples, the i-tag array holds an "overflow" dispatch. For example, if a row in the desired SRQ (eg, SRQ entry x) is still in use, the dispatch writes the information to the i-tag array. When the SRQ entry x is deallocated, the corresponding row in the SRQ overflow i-tag structure is read and copied to the main SRQ i-tag array structure (reading the overflow i-tag structure is Controlled by the existence of valid entries in the overflow i-tag array for a particular thread / region). In which physical row at the time of issuing the storage, the i-tag array of the main SRQ0 / 1 is processed by the CAM port (or searched 1/2 in SMT4) and the ISU issues the storage based on the i-tag. Decide if you want to write. The SRQ220 transmits an i-tag to the ISU when storage / discharge and deallocation occur.

FIG. 4 is an exemplary block of an effective address directory structure (L1 cache) 290 according to one embodiment. In one or more examples, EAD is part of LSU104. As shown in FIG. 3, the EAD290 consists of one or more entries (eg, entries 0-N), each entry containing multiple fields of information about a group of one or more instructions. I'm out. For example, in one embodiment, each entry in EAD290 may represent one to 32 instructions. The entry in EAD290 is created in response to an instruction fetch in a new cache line in the processor cache (eg, L2 cache 260 in FIG. 2). The entries in EAD290 are updated when additional instructions are fetched from the cache line. Each entry in EAD290 is a selected branch (ie, the branch instruction fetched from the cache is resolved as "selected"), a cache line crossing (ie, the next fetched instruction is now It ends with a cache line that is different from the cache line of) or a flush of the processor pipeline (for example, if a branch prediction error occurs).

As shown in FIG. 3, the fields of the entry for EAD290 are the base effective address 310, the first instruction identifier 320, the last instruction identifier 330, the end identifier 340, and the global history vector field. It includes 350, a link stack pointer field 360, a branch selection identifier 370, and a branch information field 380. The EAD290 is structured similarly to the L1 data cache. Set the associative structure. For example, in one or more examples, the associative structure is an 8-way, addressed by EA (52:56) and 32 indexes selected using the EA (0:51).

The base effective address 310 is the starting effective address (EA) of a group of instructions. Each instruction in a group of instructions has the same base EA and offset from the base EA. For example, in one embodiment, the EA is a 64-bit address containing bits 0:63. In one embodiment, the base EA may include bits 0:56 of this EA, where bits 57:61 represent an offset from the base EA for a particular instruction within a group of instructions. Bits 62 and 63 point to a particular byte of each instruction. In the embodiment, each address refers to an instruction having a length of 32 bits (that is, 4 bytes), and each byte in the memory can be addressed. The instruction cannot be further subdivided into addressable subcomponents, so bits 62 and 63 of the instruction address are always set to zero. Therefore, bits 62 and 63 do not need to be stored and can always be assumed to be zero by EAD.

The first instruction identifier field 320 stores offset bits of the effective address (eg, bits 57:61 of the EA) for the first instruction in the group of instructions corresponding to the entry in EAD290. The combination of the base EA from field 310 and the offset bit of the effective address in the first instruction identifier field 320 provides the EA to the first instruction in the group of instructions represented by the entry in EAD290. This first field 320 may be used to recover the refetch address and branch prediction information, for example, if the pipeline is flushed, as will be described later.

The last instruction identifier field 330 stores the offset bit of the effective address (eg, bit 57:61 of the EA) for the last instruction in the group of instructions corresponding to the entry in EAD290. The logic of EAD updates this field when additional instructions in the group of instructions represented by the entry in EAD290 are fetched. The logic of EAD interrupts the update of this field 330 in a particular EAD290 entry in response to the termination of the EAD290 entry when a cache line crossing or selected branch is detected. This field remains in its original state unless a pipeline flush occurs to clear some of the EAD entries. In such cases, the EAD logic updates this field to store the offset bit of the effective address of the instruction that is currently in the new last instruction in the entry as a result of the flush. This field will eventually be used for completion to free the entry in EAD290, as described later.

The end identifier field 340 is used to indicate that the entry for EAD290 has been completed and no further instruction fetch is performed to fetch the instruction in the instruction group corresponding to the entry for EAD290. .. The entry in EAD290 may be terminated for a variety of different reasons, including crossing the cache line, selecting a branch, or flushing the pipeline. Any of these conditions may cause the value in the end field 340 to be set (eg, set to a value of "1") to indicate that the entry for EAD has been completed. This field 340 is used on completion to free an entry in EAD290, as described in detail later.

The global history vector field 350 identifies the global history vector of the first instruction fetch group that created the entry in EAD290. The global history vector is used to identify the history of whether a branch was selected, as described in detail later. The global history vector is used for branch prediction purposes and helps determine if the current branch is likely to be selected based on the recent history of whether the branch was selected.

The link stack pointer field 360 identifies the link stack pointer of the first instruction fetch group that created the entry in EAD290. Link stack pointers are another branch prediction mechanism described in detail later.

The branch selection field 370 indicates whether the group of instructions corresponding to the entry in EAD290 contained the branch instruction for which the branch was selected. The value in the branch selection field 370 is updated in response to the expected selection of the branch instruction of the instruction group represented by the entry in EAD290. In addition, the entry for EAD290 is also terminated by writing an appropriate value in the end field 340 after the branch within the instruction for the entry for EAD290 has been selected. Since the branch selection field is speculatively written at the time of prediction, it may be necessary to replace the value of the branch selection field with the correct value when the branch is actually executed. For example, it may be predicted that no branch will be selected, in which case "0" will be written to the branch selection field. However, in later executions it may be detected that a branch has been selected, in which case this field must be modified by writing a value of "1". The second write occurs only if the branch is erroneously predicted.

The branch information field 380 stores various branch information used to update the branch prediction structure when the branch is resolved, or the state of the designed EA when the branch instruction is completed.

The ERT_ID field 385 stores an index into the ERT table (described further) that identifies the corresponding ERT entry. If an ERT entry is invalidated, the associated ERT_ID is invalidated and all associated entries in the L1 and L1D caches are also invalidated.

An entry in EAD290 is accessed using an effective address tag (eatag) that contains at least two parts, the base eatag and the eatag offset. In one embodiment, this eatag is a 10-bit value, much smaller than a 64-bit effective address. In one implementation, when using an EAD290 with a value of 10 bits and a size of 14 entries, the offset is a first 5 bit, called the base offset, for identifying the entries in the EAD290. And consists of a second 5 bits called the eatag offset to provide the offset for a particular instruction within the group of instructions represented by the entries in EAD290. The first bit in the five bits that identifies the entry in EAD290 is used as a circular bit to indicate whether a cycle has occurred when moving from the most significant entry to the least significant entry in EAD290. It's okay. This bit may be used to detect age. The second to fifth bits of the five bits that identify the entry in the EAD290 point to the index of the EAD and are used to identify the base EA of the instruction (ie, EA (0:56)). good. The 5-bit offset value may be used, for example, to provide bits 57:61 of the effective address of a particular instruction. This exemplary eatag is shown below.
eatag (0: 9) = low (0: 4) || offset (0: 4)
low (0): Circulation bit of the EAD indicating whether or not a cycle has occurred when moving from the highest entry to the lowest entry of the EAD.
low (1: 4): Index to EAD of 14 entries used to determine the EA (0:56) of the instruction.
offset (0: 4): EA bit 57:61 of the instruction.

FIG. 5 shows an exemplary effective real table (ERT) structure according to one or more embodiments of the invention. In one or more examples, the ERT255 contains a total of 128 entries, but in other examples the total number of entries can be different, and the number of entries is selectable or programmable. It should be noted that it may be. Further, if the LSU 104 uses multiple pipes, each pipe has a separate partition within the ERT255. In one or more examples, the predetermined maximum number of entries in ERT255 is evenly divided between the pipes. For example, in the case of two pipes (ie, two separately parallel instructions), the LSU maintains two partitions of ERT255 (eg, ERT0 and ERT1), each containing 64 (half) entries. For example, LD0 and ST0 use ERT0, and LD1 and ST1 use ERT1. In ST mode, the first partition of ERT255 is used with other partitions that are copies of the first partition, for example ERT0 is used with ERT1 that is a copy of ERT0. Alternatively, in one or more examples, if the LSU uses a single read pipe and a single storage pipe, the entire ERT255 is used as a single partition. In the following, unless otherwise specified, any one partition of ERT255 will be described.

The ERT 255 contains a valid ERT entry and is generally present for the L1 I-cache or D-cache directory (EAD290), or for the active page within the SRQ entry or LRQF entry or LMQ entry. In other words, ERT255 is a table of all active RPNs in LSUs and IFUs (L1 DC, SRQ, LRQE, LRQF, LMQ, IC). In one or more examples, when processor 106 is operating in ST mode, all entries in ERT255 are used for a single thread running. Alternatively, in one or more examples, the entries in ERT255 are split into multiple sets, and in ST mode, each set contains the same content. For example, if the ERT255 contains a total of 128 entries and supports up to 2 threads, then the ERT255 contains 2 sets of 64 entries each when the processor is operating in ST mode. , Those two sets contain the same content.

Alternatively, when processor 106 is operating in MT mode, ERT entries are split between running threads. For example, in the case of two threads, the ERT entry is split into two equal sets, the first set of entries is associated with the first thread, and the second set of entries is associated with the second thread. For example, one copy of L1 in the LD0 pipe fails, the ST0 pipe initiates T0 / T2 I-fetch: ERT0, processes T0 in SMT2 mode, processes T0 / T2 in SMT4 mode, and LD1. One copy of L1 of the pipe fails and the ST1 pipe initiates T1 / T3 I-fetch: ERT1 to process T1 in SMT2 mode and T1 / T3 in SMT4 mode.

In one or more examples, each ERT entry has at least ERT_ID (0: 6), Tid_en (0: 1), page size (0: 1), EA (0:51), and RA (8: 1). 51) includes the ERT field. The ERT_ID field is a unique index for each ERT entry. For example, the ERT_ID may include a serial number that identifies the ERT entry. The ERT_ID is stored in the ERT_ID field 285 of EAD290, and other data structures used by LSU. The TID_en field indicates whether the entry is enabled for use in MT mode and, in one or more examples, the thread identifier of the instruction using the ERT entry. In addition, the page size indicates the page size of the memory referenced by the ERT entry. The RA contains the real address associated with the ERT entry.

When RA is used to complete the execution of an instruction, LSU refers only to ERT255. As described herein, ERT255 is 1. 2. I fetch, read, or store fails L1 cache. 2. Storage from another thread in the core. Snoop (XI) from another core, as well as 4. Referenced by LSU for four functions: TLB and SLB disabling.

In the first case where I fetch, read, or store fails L1 cache, EA and threat_id are used to point to the index of ERT255, and if a valid ERT entry exists, RA from the corresponding ERT entry. Is sent to the L2 cache. SLB / TLB is used if the ERT fails, i.e., if there are no valid ERT entries for EA and threat_id.

In the second case of storage from another thread in the core, the storage ejected from the SRQ checks the ERT255 and ERTE tables (discussed further) for hits from another thread. If there are no hits from different threads, then there are no reads from another thread using the same RA. If there are hits from different threads using the same RA, LSU checks the LRQ. In rare cases, if RA is used by another thread, there will be hits from another thread. Accordingly, LSU searches the ERT table 400 to detect EA associated with a common RA. The EA is then used to look up the LRQ for a match (rejects the issuance of storage within that cycle). Since the LRQ is divided for each thread, the LSU only looks at the LRQ of the associated thread. If a matching read exists in the LRQ, the LSU flushes the oldest of the matching reads.

In the third case of snooping from another core of the processor, LSU behaves like the second case and checks for hits from any of the other threads running. In cases where the TLB / SLB is disabled, the ERT255 is also disabled.

FIG. 6 shows a flow chart of an exemplary method for accessing memory to execute an instruction by LSU, according to one or more embodiments of the invention. This instruction may be a read, store, or instruction fetch of the OoO processor 106. Upon receipt of an instruction, as shown in 505 and 510, the LSU uses the parameters of the instruction to check if the EAD290 contains an entry corresponding to that instruction. In one or more examples, the parameters used for the check include, in particular, the thread identifier, page size, EA.

If an EAD hit in EAD290 occurs in LSU (ie, the EA of the instruction matches an entry in EAD table 300), then LSU reads the contents of the matching EAD entry, as shown in 520. , Determine the corresponding ERT entry. Each EAD entry contains an ERT_ID (0: 6) field 285. As mentioned above, when an ERT entry is invalidated, the associated ERT_ID is invalidated and all associated entries in the EAD table 300 are also invalidated. Therefore, an EAD hit means an ERT hit because the ERT_ID field 285 can be used to detect an ERT entry for a read / store instruction. Thus, in the case of an EAD hit, after identifying the corresponding EAD entry, LSU reads the ERT_ID from the EAD entry and sends it to SRQ, LMQ, or LRQF, or a combination thereof, as shown in 530. The SRQ, LMQ, or LRQF, or a combination thereof, uses the EA from the identified EAD entry. For storage instructions using RA, RA from the ERT entry is read to access L2, as shown in 540 and 545. Therefore, since RA is not used anywhere other than the storage instruction, the core that implements the technical solution herein is referred to as the EA dedicated core.

Here, consider the case where the instruction fails in EAD290, that is, the case where the entry matching the EA of the instruction does not exist in the EAD table 300. As shown in 550, threat_id and EA are compared for each entry from ERT255. As shown in 555 and 530, if an ERT hit occurs, i.e., if the ERT entry matches a parameter, LSU reads RA (8:51) from the ERT entry. In the case of a read request, the LSU sends RA to the L2 cache for access (530). As shown in 540-545, in the case of a storage instruction, the LSU stores the RA in the SRQ and then sends the RA to the L2 cache when the storage is drained into the L2 cache.

As shown in 555 and 560, if an ERT failure occurs, the LSU initiates a reload of the ERT 255. In addition, ERT entry replacement is initiated. The replacement of ERT entries is based on LRU, which ensures that synonyms in the out-of-order window are tracked during this process.

By implementing the above method for reading in this way, address translation is not performed if an EA hit exists in the EA-based L1 directory. This improves the normal processor based on the L1 directory and puts the EA in the EAR table for conversion to get the RA sent to the L2 directory and beyond in the event of a read failure in the L1 directory. Cause to send.

Further, in the case of storage, the method described herein requires the LSU to examine the ERT table to determine the RA, after which this RA caches (L1) when the storage is ejected from the SRQ. , L2, memory), it is stored in the SRQR. SRQR holds all RAs for storage. RA is stored only for ejection to nests (ie, L2, memory, and other units of the memory subsystem). RA is also used to detect hazards for out-of-order executions of any type of load-hit store, store-hit-load, or load-hit-load, as used in normal solutions. There is no such thing. The RA calculation for storage occurs before the storage is complete because the LSU cannot handle the storage-related interrupt after the storage is complete (the storage may generate an interrupt related to address translation, which is an interrupt. , Processed before storage is complete). Here, the RA calculation is performed when the storage is issued (from SRQR), thus eliminating the need for the LSU to perform address translation. In this way, the storage is issued, executed out of order, then completed in order, and then the storage is ejected from the SRQ in order. No other thread or core knows about the storage (only the current thread knows) until the storage is ejected. After the store is ejected from the SRQ, the store is written to the L1 (if the line already exists in L1) and the L2 cache (if caching is enabled), at which point the store is in system 100. Known to all other threads and cores.

For instruction fetches that fail the L1 I-cache based on the EA, the EA is converted to RA using ERT255 and the RA is sent to the nest to fetch the I-cache line. Here, the LHS (load hit store), SHL (store hit load), and LHL (load hit load) are stored in a directory entry in the EA-based L1 cache (EAD290). And all are determined based on the ERT index. All entries in the EAD table 300 have a valid transformation in the ERT table 400, which transformations can be used after the LHS, SHL, and LHL have been determined. If an ERT entry is invalidated, the corresponding L1 cache entry is invalidated.

The read order change queue, LRQF, ensures that all read operations from dispatch to completion are tracked. If the read is rejected (because of a cache miss or conversion failure, or because the instruction before the read depends on it is rejected), the read is taken from the issue queue, placed on the LRQE, and read again from this LRQE. publish.

FIG. 7 shows a flow chart of a method for reloading an ERT according to one or more embodiments of the present invention. Reloading the ERT causes the creation or update of entries in the ERT based on the failure of the ERT in response to the failure of the ERT. ERT receives RA added to ERT255 and compares that RA with each entry in ERT0 and ERT1 as shown in 605. As shown in 610 and 615, if the RA does not exist in the ERT255 and a new entry can be created, the ERT255 creates a new entry containing the new ERT_ID to store the RA. New entries are created in either ERT0 or ERT1, respectively, based on the running thread being the first thread or the second thread. If the processor is operating in ST mode, ERT0 is updated. If the ERT 255 does not contain an empty slot for a new entry, the existing entry will be replaced based on the longest unused or other method, as shown in 615.

If an existing entry in ERT255 that contains the same RA as the received RA (RA being reloaded) is detected, the ERT255 will have the page size of the existing entry (0 :), as shown in 620. Compare 1) with the page size of the received RA. If the page size of an existing entry is less than the page size of the RA being reloaded, then as shown in 625, the existing entry for that RA is removed from the ERT255 and the RA with the larger page size. A new entry is added for this, including the new ERT_ID. If an existing entry has the same or larger page size and the implementation is using SDT, then the entry for RA being reloaded is SDT, as shown in 627. Created within. It should be noted that this operation does not have to be performed if the LSU is using ERTE.

If the page size of an existing entry is the same size as the RA being reloaded, ERT255 will check if the existing entry is on the local ERT of the running thread, as shown in 630. do. In this case, the local ERT refers to the ERT associated with the thread being executed (eg, ERT0 for the first thread, ERT1 for the second thread). As shown in 632, if an RA hit is in another ERT (ie, an ERT that is not a local ERT), the ERT 255 will make a new entry containing an ERT_ID that matches the ERT_ID in the non-local ERT. Create in. For example, if the RA hit is in ERT1 of the instruction being executed by thread 0, an entry containing the ERT_ID that matches the entry in ERT1 will be created in ERT0.

If the RA hit is on the local ERT instance and the EA also matches, then both the EA and RA matched the existing entry, but there was an ERT failure that caused the ERT to reload for this thread, so the ERT , That is considered to indicate that the two threads share the same mapping between EA-RA (having the same page size). Therefore, as shown in 634, the tid_en (0) or tid_en (1) bits in the existing matching entry for the bit corresponding to the reload thread are turned on to indicate this case.

As shown in 636, if an RA hit exists on a local ERT instance, the EA does not match an existing entry, and the existing entry is for the same thread as the RA being reloaded, then the ERT Identify the case of aliasing where two different EA are mapped to the same RA from the same thread. If the processor is using an SDT-based implementation, an entry for the synonym that maps to the ERT_ID, EA offset (40:51) of the existing matching entry is introduced into the SDT. If the processor uses an ERTE-based implementation, LSU rejects the instruction until it becomes non-speculative, then removes the entry from the ERT and adds the entry to the ERTE.

As shown in 638, if an RA hit exists on a local ERT instance, the EA does not match an existing entry, and the existing entry is for a different thread, then the ERT will have two EA's. Identify cases of aliasing that are mapped to the same RA from different threads. If the processor is using an SDT-based implementation, an entry for the synonym that maps to the ERT_ID, EA offset (40:51) of the existing matching entry is introduced into the SDT. If the processor is using an ERTE-based implementation, the new ERT_ID will be used to add a new local ERT entry containing tid_en that is valid only for the thread in which the ERT failed.

In the above method, in an ERTE-based implementation, two threads with the same RA but different EA use two different ERT entries, and in an SDT-based implementation, two threads It facilitates that one of the conversions uses the ERT entry and the other conversion uses the SDT entry when they have the same RA but different EA. Therefore, the ERT entry facilitates the case where the same EA and the same RA are used across different threads by including the tid_en field within the ERT entry. For example, in the ERT0 instance, Tid_en (0: 1) = {tid 0 en, tid 1 en}, and in the ERT1 instance, Tid_en (0: 1) = {tid 1 en, tid 1 en}. Further, the ERT entry facilitates the case where the same EA corresponds to different RAs across different threads by including multiple entries in ERT0 and ERT1 with each thread identifier. The ERT entry also supports cases with different EA corresponding to the same RA (cases of the same thread or different threads). Here, two cases are further described based on whether the implementation uses ERTE or SDT.

If the LSU is using an implementation that uses the SDT (Synonym Detection Table), the LSU will replace the ERT 255 when a new instruction containing a different EA corresponding to the same RA is detected when reloading the ERT. Introduce an entry to SDT. The SDT hit resumes using the EA of the original (previous) ERT entry. If the page size of the new synonym is larger than the page size in the existing ERT entry containing the matching RA, then instead of introducing the synonym into the SDT, the existing ERT entry is new (with a larger page size). Replaced by synonyms. Old ERT entries will eventually be reintroduced into the SDT as synonyms.

Alternatively, if the LSU is using an implementation that uses ERTE and the instructions containing different EA corresponding to the same RA are in different threads, the LSU will ERT a new entry with the appropriate Tid_en enabled. Introduce to the table. If the instructions are in the same thread, LSU refuses to read / store until the read / store becomes non-speculative. The LSU then deletes the existing ERT entry and places the ERT entry tagged with the I tag of the newest in-flight instruction from the thread in the ERTE table. LSU will further introduce a new EA-RA pair to the ERT table 400. This ensures that there will be no situation where two different EA's are mapped to the same RA from the same thread.

Further, referring again to the case of ERT, consider the case where the LSU receives a snoop from another core of the processor 106. Snoops can come from different cores in the system (snoops indicate different cores or threads, modifying data at the same real address). LSU also checks for storage from threads in the core as possible snoops to other threads in the core. All snoops (from other cores) or storages (from other threads in the core) are accompanied by RA. In such cases, the LSU reversely transforms the RA to determine the corresponding EA, ERT_ID, and page size based on ERT255. LSU compares this information with ERT_ID, PS, EA (40:56) stored in each of the following structures to detect snoop hits and perform appropriate actions. For example, if a snoop hit is detected in an LRQF entry, the LSU indicates a possible load-hit-load out-of-order hazard. If a snoop hit is detected in EAD290 and the snoop is from a different core, the LSU initiates L1 invalidation. If the store is from another thread to the shared line, the line will automatically get and update the new store.

Therefore, the technical solutions described herein facilitate a reduction in the chip area of the LSU by tracking only one address (EA). In addition, these technical solutions allow the processor core to run in two read / two store modes using split read / store queues, further reducing the CAM port for conversion, and powering the conversion. It also reduces consumption. Further, these technical solutions have the advantage of using only the EA to prevent the conversion to RA from being performed in the read / store path unless an EAD failure occurs. Furthermore, detecting hazards such as LHL, SHL, LHS, and suppressing DVAL over time does not cause timing problems. Since the LSU uses only EA, detection of LHS, SHL, LHL may fail if two different EA are mapped to the same RA. The technical solutions described herein address such technical challenges by using the EA and ERT indexes from EAD. In addition, upon detection of the EA synonym, the LSU processes the instruction by using the SDT or ERTE table for the instruction in the OoO window.

If the LSU uses the SDT (as opposed to the ERTE) and a snoop hit is present in the LMQ, the LSU also updates the LMQ entry so that it is not stored in the L1D cache and the SRQ entry becomes a snoop in the SRQ. Not used, the LHS EA is used only for checking forms that fail RA hits, and a new SDT entry is created for snoop hits.

FIG. 8 shows an exemplary structure of a synonym detection table (SDT) 700 according to one or more embodiments of the invention. It should be noted that the example depicted shows the case containing 16 entries, but in other examples the SDT700 may contain a different number of entries than this example. The SDT 700 is common across multiple threads and pipes of the LSU 104. For example, LD0, LD1, ST0, and ST1 all access the entries in the SDT700, and the SDT700 does not contain a separate partition for each.

The entries in the SDT700 are at least the issue address {issue Tid (0: 1), issue EA (0:51)}, page size (0: 1) (eg 4k, 64k, 2MB, 16MB), and resume. Includes fields for the address {EA (40:51), ERT ID (0: 6)}. The Tid (thread-identifier) field indicates which thread from the OoO processor is executing the instruction associated with the entry in the SDT700. If the start is an instruction that fails L1, the LSU compares the instruction to the SDT700. If the initiated instruction hits the SDT in comparison to the original address, LSU rejects the instruction and resumes the instruction using the corresponding substitution address from the SDT entry. For example, LSU uses the substitution address (40:51) for SRQ LHS to "force match" the ERT ID in the execution pipeline.

As described herein, an entry is added to the SDT 700 during the reloading of the ERT. For example, during an ERT reload, the reload RA is compared against valid ERT entries. If an ERT entry containing a matching RA already exists and only the additional tid_en bits are not the case of an EA hit set in the original ERT entry, then the EA (32:51) is read from the existing ERT entry. Instead of adding the entry to the ERT255, the entry is introduced into the SDT700.

Since the SDT700 has a limited number of entries, the entries are replaced. In one or more examples, entries are replaced based on the longest recently used (LRU) method or any other method. In one or more examples, if the SDT entry is replaced, a subsequent start using the secondary address will re-trigger the introduction sequence of the SDT entry. In addition, the CAM clears the SDT entry containing the ERT ID that matches the invalidated ERT entry.

FIG. 9 shows a flow chart of a method for performing an ERT and SDT EA exchange according to one or more embodiments of the invention. In one or more examples, the LSU performs the exchange if the ERT and SDT entries have the same page size. This exchange improves the efficiency of the processor 106 when different EA's correspond to the same RA with different instructions in the same thread or different threads. For example, consider two instructions x and y such that EAx => Raz and EAy => Raz. First, if EAx fails ERT, i.e., prior to EAy, LSU introduces an ERT entry containing the mapping of EAx to Raz, as described herein. Then, if the EAy fails the ERT, the LSU searches the ERT using RAz, hits the RA, and introduces an entry into the SDT700 containing the original address = EAy and the replacement address = EAx.

Here, if most subsequent access to Raz is accompanied by EAy, the LSU needs to use the SDT more often than it does with the EAD itself. In one or more examples, a technical solution for improving the efficiency of LSUs by reducing such frequent references to SDTs comprises incrementing the counter in each SDT entry. As shown in 810 of FIG. 8, the LSU initiates an instruction containing an ERT ID that matches the ERT ID from the SDT entry. If the ERT IDs of the SDT entries match, the LSU further compares the EA of the initiated instruction with the original EA in the SDT entry, as shown in 820. As shown in 830 and 835, if the SDT entry contains the original address value that matches the EA from the instruction, the counter for the SDT entry is incremented. As shown in 840, if the initiated instruction contains an EA that is different from the original address of the SDT entry, the SDT entry counter is reset.

In one or more examples, the counter is a 4-bit field, meaning a maximum of 15. In other examples, it should be understood that the fields used as thresholds are of different lengths, have different maximum values, or both. For example, as shown in 845 and 850, the counter value is compared to the threshold after the instruction is started. If the counter is below the threshold, LSU continues to operate as described. If the counter exceeds the threshold or, in some cases, equals the threshold, LSU invalidates the ERT entry corresponding to the SDT entry, as shown in 860. For example, the ERT entry containing the ERT ID from the SDT entry is invalidated. Invalidating an ERT entry causes invalidation of the corresponding entry from the EA directory, LRQF, LMQ, and SRQ.

In addition, LSU addresses the technical challenges of exceptions in initiated instructions that require the original EA to terminate in the following manner: For example, if the started instruction hits the SDT and you want to resume using the replacement address from the SDT entry instead of the original starting address, but an exception is selected that requires the original EA to exit. think about. Such a condition may occur in the case of DAWR / SPAR and the like.

LSUs that implement the technical solutions described herein address such technical challenges by keeping the original address in a queue within the LRQE. The LRQE also maintains an SDT hit flag (bit) and an SDT index (0: 3) for each RQE entry. At restart, the SDT index is read one cycle earlier to get the replacement address. The LRQE is further multiplexed between the address of the LRQE entry (original address) and the replacement address of the SDT (read from the SDT) prior to resumption. In exceptional cases like the one above where the original address is needed to exit, the LRQE contains an additional SDT hit override flag (bit) for each entry set, such as with a partial DAWR match. .. LRQE resumes the case where there was an SDT hit that ends with an exception and forces the original address to start. The resumption of the SRQ is similar to the resumption of the LRQE described herein, and the SDT hit override flag is used if it is determined to terminate with an exception prior to the resumption.

FIG. 10 shows an ERT deletion (ERTE) table 900 according to one or more embodiments of the invention. The ERTE table 900 makes it easy for LSU to track deleted (or invalidated) rows from ERT255. The ERTE table 900 makes it even easier to check if different EA's for the same RA exist in the same thread when an entry is made in ERT255. The ERTE table 900 is shared by all concurrent threads. In one or more examples, part of the ERTE table 900 is reserved for NTC entries. The entries in the ERTE table 900 include fields for thread ID, I tag, EA, and RA. In one or more examples, the ERTE table entry may contain additional fields. In one or more examples, the thread ID may be a 4-bit field.

The ERTE table 900 can be considered as a combination of two tables (ERT_EA and ERT_RA) having a one-to-one correspondence. The ERT_EA table uses EA to search, and the ERT_RA table uses RA to search. In one or more examples, each table contains 64 entries, while in other examples the number of entries may be variable / programmable. If the EA-RA conversion is removed from the ERTE table 900, the associated cache line from the EAD table 300 is also invalidated. In that way, the ERT 255 becomes a superset of all translations (except TLB, SLB) in the processor core.

The ERTE table 900 keeps track of all transformations that are not in ERT255 but are used by in-flight instructions. The ERTE table entry is tagged with the newest instruction that may have used the deleted entry. Due to the read / store OOO issue, the newest I-tag of all active instructions in the OOO window is stored in the ERTE table 900. Upon flushing, the I tag of the last remaining instruction is stored in all valid entries. Upon completion, all entries containing the same I-tag or older I-tags will be released. If the ERTE table 900 is full, it blocks the dispatch, waits for the instruction to complete (or is flushed, or both), and finally the table is completely freed. The examples described herein use the I tag to track the age of the initiated instruction, while in other examples another tag that monotonically increases and circulates (EA tag, LS tag). Etc.) should be noted that may be used instead.

If the conversion in ERT255 or EAD290 is deleted / invalidated, the EA-RA of the deleted entry will be ERTE without including the last predetermined number of bits (eg, the last 12 bits) from the deleted entry. Added to table 900. In addition, entries in the ERTE table 900 containing the newest valid I-tag of the same thread to which the deleted transformation belongs are marked, for example, using flags (bits).

When a new address translation (EA to RA) is performed, LSU compares RA to ERT255 and checks if different EA from the same thread to RA already exists in ERT255. If present, LSU introduces a new transformation into ERT255 as a synonym. In this way, the ERT255 (when using ERTE) can contain two entries containing different EA pointing to the same RA in the same thread. In one or more examples, the LSU only initiates a flush of NTC + 1 to ensure forward, as synonyms for in-flight orders are not allowed.

Balance flush is a thread control that flushes the threads of interest from the system as a whole, either stopped, consumes resources, or both, to restore fairness or balance of resource usage. It is a mechanism. Balanced flushing includes flushing all instruction groups on the selected thread following the instruction group to be executed next, flushing the next instruction to be executed (NTC + 1). NTC + 1 balanced flush flushes the execution unit, global completion table, and EAD for the selected thread. A balance flush is performed on the thread only if the thread is dispatched down. Balance flushing may be enabled or disabled using the <bf: 1> field in the thread switching control register.

In one or more examples, the entry in the ERTE is marked as invalid after the execution of the OoO window is complete. It should be noted that the ERTE entry is marked as valid when the ERTE entry is written using the new EA-RA conversion pair that has been removed from the ERT table 255.

FIG. 11 shows a flow chart of an exemplary method for adding an entry to the ERTE table 900, according to one or more embodiments of the invention. As described herein, when a new entry is added to ERT255, the LSU may manage both the EA and RA of the new transformation by the LRU, as shown in 1010. Write to a specific line. As shown in 1012, the ERTE table 900 is searched using the RA to check if the RA already exists in the entry in the ERTE table 900 corresponding to another EA and in the deployment. Check for possible multiple hits in the same thread. If the RA already exists in the ERTE table 900, the ERT table refuses to create an entry for the EA-RA up to the NTC and introduces it when the NTC is detected, as shown in 1015.

As shown in 1020, the LSU reads the EA and RA of the existing entry in the ERT that is overwritten by the new entry before overwriting the entry in ERT255, as shown in 1030. Further stores the read entries in the ERTE table 900. Further, as shown in 1040 and 1050, the ERTE table 900 searches and reads the EA if there is a snoop or stowed discharge from another core of the processor.

FIG. 12 shows an exemplary sequence diagram of an exemplary set of instructions initiated according to one or more embodiments of the invention. Each instruction is shown in program order on the left and starts with OoO, causing a sequence of actions that is different from the sequence of instructions. For example, consider that the following events occur in chronological order. 1. 1. The instruction M was issued in OoO and used the conversion "ea1, ra1". 2. 2. Command K was issued on OoO, failed ERT, introduced a new entry, and removed "ra2 ea2" from ERT. At this point, the last I tag in use = N (all lines deleted from the same thread), i.e., instructions up to N can use "ra2 ea2", after N. The instruction cannot use "ra2 ea2". 3. 3. Command H was issued by OoO, failed ERT, and deleted "ra1 ea1" from ERT. At this point, the last I tag in use = Q. 4. The flushed pipeline and the last instruction left have an I tag = E, and the next instruction to be fetched is R, S. 5. Instructions E-R complete in a given cycle, freeing all entries in the ERTE.

The technical solutions described herein thus facilitate the use of EA alone, with no reference to EAR (usually used by the processor) in the read / store path, and further. , Achieve a technical advantage so that detection of SHL and suppression of DVAL in time do not cause timing problems. In addition, the technical solutions described herein are technical problems associated with using only EA, eg, detection of LHS, SHL, LHL when two different EA are mapped to the same RA. Address issues such as may fail. The technical solutions described herein address such technical problems by using either the synonym detection table (SDT) or the ERT deletion table for instructions in the OoO window. These technical solutions include a variety of technical solutions, including, among other things, reduced chip area (by not storing RA), reduced power consumption (by not converting EA-RA), and improved latency. Achieve superiority.

In addition, these technical solutions promote power consumption savings by removing the search to determine the RA for the EA in all read and store address generation. Instead, EA is used until EAD failure and ERT failure occur. In addition, these technical solutions facilitate the elimination of RA bus switching across the unit, as only a single CAM port will be used.

FIG. 13 indicates instructions by the LSU 104 in multipipe mode and in the OoO way, depending on whether the processor is operating in ST mode or MT mode, according to one or more embodiments of the invention. A flowchart of an exemplary method for publishing is shown. For example, LSU may operate in 2 read / 2 storage modes (multipipe mode). As shown in block 1310, the LSU 104 selects the instruction to be issued from the OoO window. The selected instruction may be a read instruction, a storage instruction, or any instruction derived from such an instruction issued by LSU104 (eg, a LARX instruction).

As shown in block 1320, the LSU 104 determines whether the OoO processor is operating in ST mode or MT mode. When ST mode is used, the processor is using a single thread and the LSU 104 determines only the LSU pipe associated with the instruction, as shown in block 1330. For example, if the instruction is a read instruction, the LSU 104 may associate the read instruction with any of the LD0 pipe, LD1 pipe, or any other read pipe. Alternatively, if the instruction is a storage instruction, the LSU 104 may associate the storage instruction with any of the ST0 pipe, ST1 pipe, or any other storage pipe.

Further, as shown in block 1340, the LSU 104 uses the partitions in the LRQF218, SRQR220, LRQE222, and ERT255 associated with the pipe to create / access entries and issue instructions. For example, if the instruction is a read instruction and the associated pipe is LD0, the instruction will use entries from partitions LRQF0, LRQE0, and ERT0. Similarly, for storage instructions on pipe ST0, partitions SRQR0 and ERT0 are used. For LD1 or ST1 pipes, the LRQF1, LRQE1, ERT1 and SRQR1 partitions are used. Entries are created in the partition on a first-in, first-out basis.

Alternatively, if the processor is operating in MT mode, i.e., multiple threads are running at the same time, the LSU 104 is the thread of the thread associated with the selected instruction, as shown in block 1350. Determine the identifier. As shown in block 1360, the LSU 104 further determines the LSU pipe associated with the instruction. Further, as shown in block 1370, the LSU 104 identifies the partitions of LRQF218, SRQR220, LRQE222, and ERT255 and their locations within the partitions to create / access entries and {thread ids and pipes}. Issue an instruction based on the combination of. For example, LSU limits specific threads to specific pipes, for example, even-numbered threads to LD0 and ST0, and odd-numbered threads to LD1 and ST1. It should be noted that the classification of threads and pipes may be different in other examples. LD0 and ST0 pipes are associated with partitions suffixed with "0", and LD1 and ST1 pipes are associated with partitions suffixed with "1" (or vice versa). Will be).

In one or more embodiments of the invention, each partition is further subdivided according to the number of threads the processor is running in MT mode. For example, if the processor is running four threads, the two partitions in the LSU will each have two parts (the first partition for the first thread and the second part for the second thread). It is further divided and each partition is associated with a pair of threads. In one or more other embodiments where the number of threads in MT mode is different from four, the partition is divided into different numbers of parts based on the number of threads associated with each partition. In the above example, where a pair of threads is associated with each partition and each partition is further divided into equal parts, the first thread of the pair uses the first part and the second thread is the second. Use the part. Therefore, the instruction executed at T0 of LD0 / ST0 is associated with the first part of the partition of LRQF0, LRQE0, SRQR0, and ERT0, and the instruction executed at T2 of LD0 / ST0 is LRQF0, LRQE0, Associated with the second part of the SRQR0, and ERT0 partitions. Further, the instructions executed at T1 of LD1 / ST1 are associated with the first part of the partition of LRQF1, LRQE1, SRQR1 and ERT1, and the instructions executed at T3 of LD1 / ST1 are LRQF1, LRQE1. Associated with the second part of the SRQR1 and ERT1 partitions.

Here, reference is made to FIG. 14, which is a block diagram of a computer system 1400 for implementing some or all embodiments of one or more embodiments of the present invention. The processes described herein may be implemented in hardware, software (eg, firmware), or a combination of hardware and software. In embodiments, the methods described may be implemented in hardware, at least in part, and may be a dedicated or general purpose computer such as a mobile device, personal computer, workstation, microprocessor, or mainframe computer. It may be part of the microprocessor of the system 1400.

In an example embodiment, as shown in FIG. 14, the computer system 1400 is a processor 1405, a memory 1412 coupled to a memory controller 1415, and one or more input devices 1445, or local I / O. Includes output devices 1447 such as peripherals coupled via communication via controller 1435, or a combination thereof. These devices 1447 and 1445 may include, for example, printers, scanners, microphones and the like. The conventional keyboard 1450 and mouse 1455 may be coupled to the I / O controller 1435. The I / O controller 1435 may be, for example, one or more buses or other wired or wireless connections known in the art. The I / O controller 1435 may include additional elements such as a controller, buffer (cache), driver, repeater, and receiver for enabling communication, which are omitted for simplicity.

I / O devices 1447, 1445 access, for example, disk and tape storage, network interface cards (NICs) or modulators / demodulators (other files, devices, systems, or networks). It may further include devices that communicate with both inputs and outputs, such as radio frequency (RF) or other transceivers, telephone interfaces, bridges, routers, and so on.

Processor 1405 is a hardware device for executing hardware instructions or software, specifically software stored in memory 1412. Processor 1405 is a custom-made or commercially available processor, central processing unit (CPU), auxiliary processor between multiple processors associated with computer system 1400 (microchip or chip set). It may be a semiconductor-based microprocessor (in the form of), a macroprocessor, or any other device for executing instructions. Processor 1405 includes an instruction cache for speeding up the fetching of executable instructions, a data cache for speeding up fetching and storing data, and a virtual address-to-physical address translation of both executable instructions and data. Can include, but is not limited to, caches such as translation look-aside buffers (TLBs) used to speed up. The cache may be structured as a hierarchy of more cache levels (L1, L2, etc.).

The memory 1412 includes a volatile memory element (eg, random access memory (RAM) such as DRAM, SRAM, SDRAM) and a non-volatile memory element (eg, ROM, erasable programmable read-only memory (EPROM:). erasable programmable read only memory), electronically erasable programmable read only memory (EEPROM: electronically erasable programmable read only memory), programmable read only memory (PROM: programmable read only memory), tape, compact disk read only memory (CD- ROM: compact disc read only memory), disc, floppy (R) disc, cartridge, cassette, etc.) may be included. In addition, the memory 1412 may incorporate electronic, magnetic, optical, or other types of storage media. Note that memory 1412 can include a distributed architecture in which the various components are located far apart from each other but may be accessed by processor 1405.

The instructions in memory 1412 may include one or more separate programs, each of which contains an ordered list of executable instructions for implementing a logical function. In the example of FIG. 14, the instructions in memory 1412 include an appropriate operating system (OS) 1411. Operating system 1411 can essentially control the execution of other computer programs, providing scheduling, input / output control, file and data management, memory management, and communication control and related services.

For example, additional data, including instructions from processor 1405 or other retrievable information, may be stored in storage 1427, which may be a storage device such as a hard disk drive or a semiconductor drive. Instructions stored in memory 1412 or storage 1427 may include instructions that allow processor 1405 to perform one or more aspects of the dispatch system and method of the present disclosure.

The computer system 1400 may further include a display controller 1425 coupled to the display 1430. In an embodiment, the computer system 1400 may further include a network interface 1460 for coupling to the network 1465. The network 1465 may be an IP-based network for communication over a broadband connection between the computer system 1400 and an external server, client, or the like. Network 1465 sends and receives data between computer system 1400 and an external system. In an embodiment, the network 1465 may be a managed IP network managed by a service provider. The network 1465 may be implemented wirelessly using, for example, wireless protocols and technologies such as WiFi, WinMax. Network 1465 may be a packet-switched network, such as a local area network, a wide area network, a metropolitan area network, the Internet, or other similar types of network environments. The network 1465 includes a fixed wireless network, a wireless local area network (LAN), a wide area network (WAN), a personal area network (PAN), and a virtual private network (PAN). It may be a virtual private network), the Internet, or any other suitable network system, and may include equipment for transmitting and receiving signals.

Systems and methods for providing split read and store request queues are embodied in whole or in part in computer program products or in computer system 1400 as shown in FIG. Can be done.

In the present specification, various embodiments of the present invention will be described with reference to the relevant drawings. Alternative embodiments of the invention can be devised without departing from the scope of the invention. In the following description and drawings, various connections and positional relationships between the elements (eg, top, bottom, adjacency, etc.) are shown. Their connections and / or positional relationships can be direct or indirect, unless otherwise specified, and the invention is not intended to be limited in this regard. Therefore, the connection of each entity can refer to a direct connection or an indirect connection, and the positional relationship between the entities can be a direct positional relationship or an indirect positional relationship. In addition, the various work and process steps described herein may be incorporated into more comprehensive procedures or steps that include additional steps or functions not described in detail herein.

The following definitions and abbreviations are used in the claims and interpretation of the specification. As used herein, "prepare", "prepare", "contain", "contain", "have", "have", "contain", "contain". The term "is", or any other variant of these, is intended to cover non-exclusive inclusion. For example, a composition, mixture, process, method, product, or device that includes a list of elements is not necessarily limited to those elements and is not specified or such composition, mixture, process, method. Can include other elements that are specific to, product, or device.

In addition, the term "exemplary" is used herein to mean "act as an example, case, or example." The embodiments or designs described herein as "exemplary" should not necessarily be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" may be understood to include any one or more integers (ie, 1, 2, 3, 4, etc.). The term "plurality" may be understood to include any integer greater than or equal to 2 (ie, 2, 3, 4, 5, etc.). The term "connection" may include both indirect "connection" and direct "connection".

The terms "about," "substantially," "approximately," and these variants include the degree of error associated with a particular quantity of measurement, based on the equipment available at the time of filing of this application. Is intended to be. For example, "about" can include a range of ± 8% or 5%, or 2% of a particular value.

For the sake of brevity, conventional techniques relating to the creation and use of aspects of the invention may or may not be described in detail herein. Specifically, different aspects of computing systems and specific computer programs for implementing the various technical features described herein are well known. Therefore, for brevity, many prior implementation details are given here only briefly or omitted altogether, without providing details of known systems and / or processes. Will be done.

The present invention may be a system, method, computer program product, or a combination thereof. The computer program product may include a computer-readable storage medium containing computer-readable program instructions for causing the processor to perform aspects of the invention.

The computer-readable storage medium can be a tangible device that can hold and store instructions for use by the instruction execution device. The computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof, but is limited thereto. Not done. A non-exhaustive list of more specific examples of computer-readable storage media is portable floppy (R) disks, hard disks, random access memory (RAM), read-only memory (ROM: read). -onlymemory), erasable programmable read-only memory (EPROM: eraseableprogrammable read-only memory or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD) -ROM: compact disc read-only memory), digital versatile disk (DVD), memory sticks, floppy (R) discs, punch cards or raised structures in grooves where instructions are recorded, etc. Includes mechanically encoded devices, and any suitable combination of these. As used herein, a computer-readable storage medium itself passes through a radio wave or other freely propagating electromagnetic wave, a waveguide or other transmitting medium propagating electromagnetic wave (eg, an optical fiber cable). It should not be construed as a transient signal, such as an optical pulse) or an electrical signal transmitted over a wire.

The computer-readable program instructions described herein are from a computer-readable storage medium to each computing device / processing device, or a network (eg, the Internet, a local area network, a wide area network, or a wireless network, or a network thereof). Can be downloaded to an external computer or external storage device via a combination). This network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface within each computing device / processing device receives computer-readable program instructions from the network and these computer-readable program instructions are computer-readable within each computing device / processing device. Transfer for storage on a storage medium.

The computer-readable program instructions for performing the operation of the present invention include assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcodes, firmware instructions, state setting data, and the like. Alternatively, any one or more programming languages, including object-oriented programming languages such as Java (R), Smalltalk (R), C ++, and traditional procedural programming languages such as the "C" programming language or similar programming languages. It may be source code or object code written in a combination of. Computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer as a stand-alone software package, and partially on the user's computer and on the remote computer, respectively. It can be run, or it can be run globally on a remote computer or on a server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN). Alternatively, the connection may be made to an external computer (eg, over the Internet using an Internet service provider). In some embodiments, in order to carry out aspects of the invention, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs). The electronic circuit including) may execute the computer-readable program instruction for customizing the electronic circuit by utilizing the state information of the computer-readable program instruction.

Aspects of the invention are described herein with reference to flow charts and / or block diagrams of methods, devices (systems), and computer program products, according to embodiments of the invention. It will be appreciated that each block of the flow chart and / or block diagram, as well as the combination of blocks contained in the flow chart and / or block diagram, can be implemented by computer-readable program instructions.

These computer-readable program instructions are means by which instructions executed through the processor of a computer or other programmable data processing device perform the functions / operations specified in the block diagram and / or block diagram. It may be provided to a general purpose computer, a dedicated computer, or the processor of another programmable data processing device to create a machine. These computer-readable program instructions are such that the computer-readable storage medium in which the instructions are stored comprises a product containing instructions that implement the functional / operational mode specified in the block diagram and / or block diagram. It may be stored on a computer-readable storage medium and can instruct a computer, a programmable data processor, or other device, or a combination thereof, to function in a particular manner.

Computer-readable program instructions are such that instructions executed on a computer, other programmable device, or other device perform the functions / operations specified in the block diagram and / or block diagram. , May be loaded into a computer, other programmable data processing device, or other device to spawn a computer implementation process, thereby allowing a series of operable steps to be programmed on the computer or other. It may be run on a device or on another device.

The flowcharts and block diagrams in the figure show the architecture, function, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction that comprises one or more executable instructions for implementing a defined logical function. .. In some alternative implementations, the functions shown in the blocks may occur in a different order than shown in the figure. For example, two blocks shown in succession may actually be executed at substantially the same time or, in some cases, in reverse order, depending on the functions included. Each block of the block diagram and / or flow chart, and the combination of blocks contained in the block diagram and / or flow chart, either performs the specified function or operation, or is a combination of dedicated hardware and computer instructions. Also note that it can be implemented by a dedicated hardware-based system that runs.

Descriptions of the various embodiments of the invention are presented for illustrative purposes, but are not intended to be exhaustive and are not limited to the disclosed embodiments. It will be apparent to those skilled in the art that many modifications and variations are possible without departing from the scope and ideas of the embodiments described. The terms used herein are to best describe the principles of the embodiment, the actual application, or technical improvements beyond the techniques found on the market, or are disclosed herein by those of ordinary skill in the art. It has been selected to help you understand the embodiments.

Claims (20)

A processing unit for executing one or more instructions, wherein the processing unit is
It comprises a read / store unit (LSU), the LSU being configured to use multiple LSU pipes to execute multiple instructions in an out-of-order (OoO) window.
The selection of an instruction from the OoO window, wherein the instruction uses an effective address.
In response to the instruction being a read instruction
Creates an entry in the first partition of the read reorder queue based on the instruction being issued on the first read pipe in response to the processing unit operating in single thread mode. And, based on the fact that the instruction was issued on the second read pipe, creating the entry in the second partition of the read order change queue.
Based on the fact that the instruction is issued on the first read pipe in response to the operation of the processing unit in a multithreaded mode in which a plurality of threads are processed simultaneously, the processing unit of the processing unit A processing unit executed by a first thread by creating the entry in the first predetermined portion of the first partition of the read order change queue. In the multithreaded mode, the first predetermined portion of the first partition of the read order change queue is issued by the first thread of the processing unit using the first read pipe. The processing unit according to claim 1, which is specific to the read instruction. The read / store unit
In response to the instruction being a storage instruction
A storage entry in the first partition of the storage order change queue based on the fact that the storage instruction was issued on the first storage pipe in response to the processing unit operating in the single thread mode. And creating the storage entry in the second partition of the storage order change queue based on the fact that the storage instruction was issued on the second storage pipe.
In response to the operation of the processing unit in the multithreaded mode, the storage instruction is issued on the first storage pipe by the first thread of the processing unit. The processing unit of claim 1, further configured to create the storage entry in a first predetermined portion of the first partition of the storage order change queue. The processing unit according to claim 1, wherein the read order change queue includes one partition for each read pipe of the LSU. The processing unit according to claim 4, wherein the LSU operates a plurality of read instructions at the same time, and one read instruction uses each read pipe. The processing unit according to claim 3 , wherein the storage order change queue includes one partition for each storage pipe of the LSU. The processing unit according to claim 6, wherein the LSU operates a plurality of storage instructions at the same time, and one storage instruction uses each read pipe. A computer implementation method for out-of-order execution of one or more instructions by a processing unit.
Receiving an out-of-order (OoO) window of instructions containing multiple instructions executed out of order by the processing unit's read / store unit (LSU).
The LSU comprises issuing an instruction from the OoO window, the instruction.
The selection of an instruction from the OoO window, wherein the instruction uses an effective address.
In response to the instruction being a read instruction
Creates an entry in the first partition of the read reorder queue based on the instruction being issued on the first read pipe in response to the processing unit operating in single thread mode. And, based on the fact that the instruction was issued on the second read pipe, creating the entry in the second partition of the read order change queue.
The read by the first thread of the processing unit based on the instruction being issued on the first read pipe in response to the operation of the processing unit in multithreaded mode. A computer implementation method issued by creating the entry in the first predetermined portion of the first partition of the reordering queue. In the multithreaded mode, the first predetermined portion of the first partition of the read order change queue is issued by the first thread of the processing unit using the first read pipe. The computer implementation method according to claim 8, which is specific to the read instruction. In response to the instruction being a storage instruction
A storage entry in the first partition of the storage order change queue based on the fact that the storage instruction was issued on the first storage pipe in response to the processing unit operating in the single thread mode. And creating the storage entry in the second partition of the storage order change queue based on the fact that the storage instruction was issued on the second storage pipe.
In response to the operation of the processing unit in the multithreaded mode, the storage instruction is issued on the first storage pipe by the first thread of the processing unit. The computer implementation method of claim 8, further comprising creating the storage entry in a first predetermined portion of the first partition of the storage order change queue. The computer implementation method according to claim 8, wherein the read order change queue includes one partition for each read pipe of the LSU. The computer implementation method according to claim 11, wherein the LSU operates a plurality of read instructions at the same time, and one read instruction uses each read pipe. The computer implementation method according to claim 10 , wherein the storage order change queue includes one partition for each storage pipe of the LSU. 13. The computer implementation method according to claim 13, wherein the LSU operates a plurality of storage instructions at the same time, and one storage instruction uses each read pipe. A computer program product comprising a computer-readable storage medium in which a program instruction is embodied, the program instruction being transmitted to a processing unit.
Receiving an out-of-order (OoO) window of instructions containing multiple instructions executed out of order by the processing unit's read / store unit (LSU).
The LSU can be executed by the processing unit to perform an operation including issuing an instruction from the OoO window, and the instruction is:
The selection of an instruction from the OoO window, wherein the instruction uses an effective address.
In response to the instruction being a read instruction
Creates an entry in the first partition of the read reorder queue based on the instruction being issued on the first read pipe in response to the processing unit operating in single thread mode. And, based on the fact that the instruction was issued on the second read pipe, creating the entry in the second partition of the read order change queue.
The read by the first thread of the processing unit based on the instruction being issued on the first read pipe in response to the operation of the processing unit in multithreaded mode. A computer program product issued by creating the entry in the first predetermined portion of the first partition of the reordering queue. In the multithreaded mode, the first predetermined portion of the first partition of the read order change queue is issued by the first thread of the processing unit using the first read pipe. The computer program product according to claim 15, which is specific to the read instruction. In response to the instruction being a storage instruction
A storage entry in the first partition of the storage order change queue based on the fact that the storage instruction was issued on the first storage pipe in response to the processing unit operating in the single thread mode. And creating the storage entry in the second partition of the storage order change queue based on the fact that the storage instruction was issued on the second storage pipe.
In response to the operation of the processing unit in the multithreaded mode, the storage instruction is issued on the first storage pipe by the first thread of the processing unit. 15. The computer program product of claim 15, comprising creating the storage entry in a first predetermined portion of the first partition of the storage order change queue. 15. The computer program product of claim 15, wherein the read order change queue contains one partition for each read pipe of the LSU. 18. The computer program product of claim 18, wherein the LSU operates a plurality of read instructions simultaneously, with one read instruction using each read pipe. 17 . Described computer program products.

Images