US20090138681A1 - Synchronization of parallel processes - Google Patents
Synchronization of parallel processes Download PDFInfo
- Publication number
- US20090138681A1 US20090138681A1 US12/360,310 US36031009A US2009138681A1 US 20090138681 A1 US20090138681 A1 US 20090138681A1 US 36031009 A US36031009 A US 36031009A US 2009138681 A1 US2009138681 A1 US 2009138681A1
- Authority
- US
- United States
- Prior art keywords
- processor
- instruction
- instructions
- speculation
- machine
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
- 238000000034 method Methods 0.000 title claims abstract description 61
- 238000012545 processing Methods 0.000 claims description 33
- 230000001360 synchronised effect Effects 0.000 claims description 5
- 238000013459 approach Methods 0.000 description 4
- 230000008901 benefit Effects 0.000 description 4
- 238000010586 diagram Methods 0.000 description 4
- 230000000694 effects Effects 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000007613 environmental effect Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/3004—Arrangements for executing specific machine instructions to perform operations on memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/30003—Arrangements for executing specific machine instructions
- G06F9/30076—Arrangements for executing specific machine instructions to perform miscellaneous control operations, e.g. NOP
- G06F9/30087—Synchronisation or serialisation instructions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3824—Operand accessing
- G06F9/3834—Maintaining memory consistency
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3836—Instruction issuing, e.g. dynamic instruction scheduling or out of order instruction execution
- G06F9/3842—Speculative instruction execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3854—Instruction completion, e.g. retiring, committing or graduating
- G06F9/3856—Reordering of instructions, e.g. using queues or age tags
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3854—Instruction completion, e.g. retiring, committing or graduating
- G06F9/3858—Result writeback, i.e. updating the architectural state or memory
- G06F9/38585—Result writeback, i.e. updating the architectural state or memory with result invalidation, e.g. nullification
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/30—Arrangements for executing machine instructions, e.g. instruction decode
- G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
- G06F9/3861—Recovery, e.g. branch miss-prediction, exception handling
- G06F9/3863—Recovery, e.g. branch miss-prediction, exception handling using multiple copies of the architectural state, e.g. shadow registers
Definitions
- the present disclosure describes systems and techniques relating to program flow control, for example, synchronizing parallel processes.
- a process is an executing software program, which may or may not share resources with other processes.
- Parallel processes are two or more processes that operate together in a computing system (e.g., parallel threads of a program) and share at least one system resource that may not be accessible by all the parallel processes together (e.g., a shared memory resource that may be corrupted if accessed in parallel by multiple processes). Access to such shared resources frequently needs to be synchronized, and this is typically done by placing shared-resource-access operations in a critical section of a program.
- a critical section of a program may enforce serialized access to a shared resource among parallel processes. Traditionally this has been done using some form of atomic operation.
- An atomic operation is multiple sub-operations on a resource (e.g., read, modify and then write to a memory location) that the processor architecture forces to be performed together by not allowing multiple processes to overlap their performance of the multiple sub-operations.
- an atomic read-modify-write instruction may be provided for use with a lock variable for a critical section; or support for a semaphore may be provided for use in controlling how many parallel processes can access a critical section.
- the processor architecture enables a simple shared resource to be made into a protected resource (e.g., a protected variable), which must be shared sequentially because of the processor architecture itself, allowing programmers to synchronize access to any number, and type of shared resources.
- FIG. 2 illustrates synchronization of parallel processes using processor speculation and cache coherence maintenance.
- FIG. 3 is a block diagram illustrating a data processing machine.
- FIG. 1 is a flowchart illustrating synchronization of parallel processes.
- Parallel processes are generated in a data processing machine at 100 .
- a software program may be run that spawns multiple threads in the data processing machine.
- the term “parallel processes” refers to the broad software design concept of parallel processing operations with a shared resource, and is not limited to a particular hardware and operating system design.
- the parallel processes are multiple threads of control, which may be parallel threads, tasks, or system processes with different process identifiers in a multitasking operating system (e.g., different Windows® processes in a Windows operating system).
- Output resulting from the synchronized parallel processes is provided at 120 . This output may be provided to one or more other processes in the data processing machine, or to another data processing machine.
- FIG. 3 is a block diagram illustrating a data processing machine 300 .
- the machine 300 may be a uniprocessor machine or a multiprocessor machine.
- the machine 300 may also employ various advanced processor architecture features, such as super-pipelining and/or hyperthreading.
- the machine 300 includes two or more parallel processes 310 operating in an applications layer and/or an operating system of the machine 300 . Additionally, the machine 300 includes a processor/processing system in hardware, which may be an out-of-order processor/processing system, that provides speculative execution of instructions.
- An out-of-order processor may include a memory sub-system 320 and execution units 330 .
- the memory sub-system 320 may include a system bus, a bus interface unit, and a cache, which may be divided into an instruction cache and a data cache and/or into multiple levels (e.g., a level 1 cache and a level 2 cache).
- the memory sub-system 320 also may include a memory interface unit and memory order buffer (MOB).
- the execution units 330 may include integer, floating point, and multimedia (e.g., Single Instruction, Multiple Data (SIMD)) execution units.
- SIMD Single Instruction, Multiple Data
- the out-of-order processor includes an in-order front end 340 that obtains instructions, and an out-of-order execution engine 350 that re-orders the instructions received from the in-order front end 340 and provides speculative execution.
- the in-order front end may include a fetch-decode unit 342 , an instruction cache 344 , and a branch prediction unit 346 .
- the out-of-order execution engine 350 may include an out-of-order execution management unit 352 , including at least one buffer (e.g., a reorder buffer), and an in-order retire-store unit 354 .
- one or more fetch-decode units may pull instructions from a cache and decode these instructions before placing them in an execution management back end of the processor. Decoding the instructions may involve breaking up more complex instructions into smaller micro-instructions and/or translating instructions into larger macro-instructions, depending on the processor architecture.
- the out-of-order execution management unit 352 may include a dispatch-execute unit that checks instructions in a reorder buffer and processes those that have all the necessary information for execution.
- the retire-store unit 354 may inspect instructions in the out-of-order execution management unit 352 .
- the retire-store unit 354 may remove completed instructions and store instruction results temporarily until they are sent back to a cache.
- the retire-store unit 354 also may receive completed instructions directly from a dispatch execute unit and/or the execution units 330 .
- the out-of-order processor/processing system of the machine 300 has an instruction set architecture (ISA) 360 including speculative execution control circuitry that handles at least one machine instruction that facilitates synchronization between parallel processes by exposing the processor speculation to program control. For example, two new instructions, a speculative execution instruction and a speculation termination instruction, can be added to the ISA of a processor having a mechanism to execute instructions speculatively. These two new instructions can then be used to implement synchronization.
- ISA instruction set architecture
- the speculative execution (“spec”) instruction may take first and second operands (e.g., spec loc, addr), behave as a no-op if a memory location indicated by the first operand contains a non-zero value, cause the processor to speculatively execute additional instructions if the memory location contains a zero value, and cause the processor to start executing instructions from an address indicated by the second operand if a mis-speculation occurs.
- the nature of a mis-speculation during the speculative execution may depend in part on the processor architecture.
- the hardware may provide invalidation based cache coherence to detect memory dependence violation, such as may be implemented using a MOB in the memory sub-system 320 and a snoop controller in a data cache unit.
- a processor/processing unit may maintain a queue of load addresses and snoop the bus to check whether any other processor/processing unit intends to write to a memory location that it has read.
- a memory dependency violation may be handled in the same way as a branch mis-prediction: the in-flight instructions may be flushed (e.g., any stores, or other changes caused to processor state by the in-flight instructions are discarded), and the processor may begin fetching from the mis-speculation address (e.g., the second operand of the spec instruction).
- Other approaches to detecting a memory dependency violation, and to starting execution from a different address if a misspeculation occurs, are also possible.
- the speculation termination (“commit”) instruction may cause the processor to begin retiring the additional instructions if the additional instructions have been speculatively executed.
- the commit instruction brings the processor out of the speculation mode initiated by the spec instruction, and while the processor is retiring the speculative instructions, the processor continues checking for a mis-speculation (e.g., an interrupt or a dependency violation) until the processor retires the commit instruction. If the processor detects a mis-speculation, it flushes any remaining speculative instructions, and starts executing instructions from the specified address.
- a mis-speculation e.g., an interrupt or a dependency violation
- the commit instruction may take first and second operands (e.g., commit loc, addr), behave as a no-op if a memory location indicated by the first operand contains a non-zero value, and cause the processor to start executing instructions from an address indicated by the second operand if a mis-speculation occurs while the processor is retiring the speculative instructions.
- first and second operands e.g., commit loc, addr
- FIG. 5 illustrates an example code section 500 implementing synchronization according to the new approach.
- a conventional approach to implementing synchronization through an atomic read-modify-write of a memory location is as follows:
- the new approach may convert the atomic read-modify-write into a speculative read-modify-write, as follows:
- post_lock normal program flow ... If only one process/thread tries to grab the lock at any time, then the speculative read-modify-write (lines 1, 2, and 3 above) may occur without any mis-speculation, and as a result, the read-modify-write gets committed, and hence the process/thread gets to own the lock. However, if multiple processes/threads attempt to acquire the lock at the same time, then this results in a mis-speculation because line 1 is a read from a memory location and line 3 is a write to the same memory location, thus causing a RAW dependence violation. The speculation is aborted, instructions from the shootdown label are fetched, and thus the processes/threads fall back upon the conventional method of grabbing the lock.
- the syntax for the speculative execution instruction and the speculation termination instruction in this example is merely exemplary.
- the ‘loc’ (which denotes a memory location) in the commit syntax is used to identify the previously executed spec instruction.
- the commit forms a speculation block with the spec instruction that has the same value of ‘loc’ in this example.
- another syntax is also possible.
- the commit instruction may have no operands, form a block with the previous spec instruction, and use the same shoot down address specified in the spec instruction.
- FIG. 6 illustrates a reorder buffer 600 as may be used in a processor that supports a speculative execution instruction and a speculation termination instruction.
- the reorder buffer 600 includes a head 610 and a tail 620 of the instructions in the instruction pool.
- the instructions may be in the form of micro-ops or macro-ops.
- the processor does not start retiring the first instruction in the speculative block until the last instruction, and all the intermediate instructions, have been executed and are ready to retire.
- a speculative execution instruction 610 has stopped the TBR pointer 630
- the CBR pointer 640 points to a current instruction 650
- a speculation termination instruction 670 has not yet been executed and cannot be executed until after an intermediate instruction 660 has been executed.
- the CBR pointer 640 reaches the speculation termination instruction 670 , then the TBR pointer 630 is free to advance, and the processor begins retiring instructions again. Mis-speculation checking continues while the TBR pointer 630 advances toward the CBR pointer 640 .
- the execution engine may identify any of the instructions in the block that may trigger a mis-speculation, for example an instruction that may raise an interrupt, and send a corresponding message to the front end of the processor.
- the entire speculative block of instructions (the instructions between the head and the tail of the ROB) may then be flushed from the pipeline, and a message to the in-order front-end may provide the address from where to begin fetching the new instructions to fill the reorder buffer 600 .
- the circuitry used to implement this in the processor may be similar to that used in handling branch mis-prediction in current processors.
- a MOB may detect a memory violation and then communicate this to the front-end and the reorder buffer. This causes the in-flight instructions to be flushed and new instructions to be fetched from a different location.
- the MOB may keep a buffer that contains the addresses that have been read by the instructions in the reorder buffer in a first processor (the current in-flight non-retired instructions). If a different processor writes into any of these addresses, then the different processor may send an invalidation signal to the first processor to maintain cache coherency.
- the snoop controller in the first processor monitors the invalidation signals on the bus, and if the address of any of those signals matches any of the load addresses in the MOB, then the snoop controller/MOB sends a signal to the reorder buffer and the front-end that triggers mis-speculation and the consequent recovery.
- the entire lock-check sequence (lines 1, 2, and 3) and critical section may be performed without having to disturb pipelined processing. In particular, no dependence violations are caused, and the critical section is executed without any locking operation being required.
- T i may be the first to commit the store instruction in line 3. This means that T i will have done a successful request for ownership (RFO) for the cache line containing the variable lock_var, and invalidated copies with other processors. Because the first instruction (line 1) in the speculative sequence is a load of the same memory location, the store by T i will cause a dependency violation in all the other processes/threads, and cause them to mis-speculate.
- Cache coherence enforces the fundamental property that stores to the same address are serialized. Thus, for stores to the same address by multiple processors, all the processors see the stores in some particular order, and all but one processor will be shot down due to the dependence violations. All other threads will branch to the code sequence in shoot_down and try to grab the lock by using the conventional atomic read-modify-write operation.
- FIG. 2 illustrates synchronization of parallel processes using processor speculation and cache coherence maintenance.
- Machine instructions including a memory access instruction, are speculatively executed in a processing system to effect synchronization at 200 .
- the speculatively executed machine instructions are retired at 210 .
- Cache coherence is maintained in the processing system, during the speculative execution and the retiring of the instructions, to effect the synchronization between the parallel processes at 220 . Any violation of cache coherence during the executing-retiring interval implies that synchronization was not successful. Conversely, if there was no violation, it implies that synchronization was successful.
- FIG. 4 is a block diagram illustrating a system including a multiprocessor.
- a data processing machine 420 is communicatively coupled with one or more information sources 410 through a network 400 .
- the machine 420 may include a communication interface 430 , a virtual machine 440 , and a memory 450 .
- the machine 420 includes a multiprocessor 460 , which includes multiple processors/processing units 462 .
- the multiprocessor 460 employs the systems and techniques described, and may include multiple processing units on a single die or on multiple chips.
- the machine 420 may receive software via the network 400 and send output to other data processing machines via the network 400 .
- the virtual machine 440 may translate software information indicative of instructions into one or more machine instructions that control speculative execution in the multiprocessor 460 .
- the virtual machine 440 may be a Java virtual machine that translates multi-threaded Java code into machine instructions.
- one or more environmental sensors 470 may be connected with the processor to provide information regarding the environment of the machine 420 , such as in the case where the machine 420 is a remote monitoring station.
- a possible implementation of the spec instruction is to restrict the window of speculation to the reorder buffer size, and trigger a mis-speculation otherwise. If the CBR pointer reaches the TBR pointer, which implies that a commit instruction was not found inside the ROB, then a mis-speculation is triggered. The pipeline is flushed and the processor starts fetching from the mis-speculation address.
- a single speculative instruction may be provided that commits after a certain number of speculative instructions, either a fixed number of instructions or an input number of instructions.
- An input number N may be in a third operand, which may correspond to N instructions to speculate.
- Other embodiments are also possible.
- the new instructions described can be used in other contexts as well. For example, they can be used for implementing non-faulting loads by putting the loads after the spec instruction.
- the semantics of the spec instruction ensures that the loads are committed only if they do not cause an interrupt/fault.
- Non-faulting loads can be used for software prefetching.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Advance Control (AREA)
Abstract
A speculative execution capability of a processor is exposed to program control through at least one machine instruction. The at least one machine instruction may be two instructions designed to facilitate synchronization between parallel processes. According to an aspect, an instruction set architecture includes circuitry that handles a speculative execution instruction and a speculation termination instruction. The speculative execution instruction may be an instruction that takes first and second operands, causes the processor to speculatively execute additional instructions if a memory location contains a value, and causes the processor to start executing instructions from an address indicated by the second operand if a mis-speculation occurs, and the speculation termination instruction may be an instruction that causes the processor to begin retiring the additional instructions.
Description
- This application is a continuation application of and claims the benefit of priority to U.S. application Ser. No. 10/797,886, filed Mar. 9, 2004; the disclosure of the prior application is considered part of (and is incorporated by reference in) the disclosure of this application.
- The present disclosure describes systems and techniques relating to program flow control, for example, synchronizing parallel processes.
- A process is an executing software program, which may or may not share resources with other processes. Parallel processes are two or more processes that operate together in a computing system (e.g., parallel threads of a program) and share at least one system resource that may not be accessible by all the parallel processes together (e.g., a shared memory resource that may be corrupted if accessed in parallel by multiple processes). Access to such shared resources frequently needs to be synchronized, and this is typically done by placing shared-resource-access operations in a critical section of a program.
- A critical section of a program may enforce serialized access to a shared resource among parallel processes. Traditionally this has been done using some form of atomic operation. An atomic operation is multiple sub-operations on a resource (e.g., read, modify and then write to a memory location) that the processor architecture forces to be performed together by not allowing multiple processes to overlap their performance of the multiple sub-operations. For example, an atomic read-modify-write instruction may be provided for use with a lock variable for a critical section; or support for a semaphore may be provided for use in controlling how many parallel processes can access a critical section. Thus, the processor architecture enables a simple shared resource to be made into a protected resource (e.g., a protected variable), which must be shared sequentially because of the processor architecture itself, allowing programmers to synchronize access to any number, and type of shared resources.
-
FIG. 1 illustrates synchronization of parallel processes. -
FIG. 2 illustrates synchronization of parallel processes using processor speculation and cache coherence maintenance. -
FIG. 3 is a block diagram illustrating a data processing machine. -
FIG. 4 is a block diagram illustrating a system including a multiprocessor. -
FIG. 5 illustrates an example code section implementing synchronization. -
FIG. 6 illustrates a reorder buffer as may be used in a processor that supports a speculative execution instruction and a speculation termination instruction. - Details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features and advantages may be apparent from the description and drawings, and from the claims.
-
FIG. 1 is a flowchart illustrating synchronization of parallel processes. Parallel processes are generated in a data processing machine at 100. For example, a software program may be run that spawns multiple threads in the data processing machine. The term “parallel processes” refers to the broad software design concept of parallel processing operations with a shared resource, and is not limited to a particular hardware and operating system design. The parallel processes are multiple threads of control, which may be parallel threads, tasks, or system processes with different process identifiers in a multitasking operating system (e.g., different Windows® processes in a Windows operating system). - Moreover, the parallel processes may be in a uniprocessor or multiprocessor data processing machine. Thus, the fact that the processes are “parallel”, does not mean they must run simultaneously, as would be possible in a symmetric-multiprocessing (SMP) machine, but rather that the processes are designed so that they can run concurrently and access a shared memory resource. The parallel processes may run in any order, and thus access to the shared memory resource should be synchronized to provide the proper processing results.
- Synchronization between the parallel processes is effected using processor speculation in the data processing machine at 110. The data processing machine may include an out-of-order processor/processing system that provides speculative execution of machine instructions, and this processor speculation capability is exposed to program control. Using processor speculation to implement synchronization among parallel processes may provide a significant advantage in that, if a critical section of a program happens to be uncontended at runtime (e.g., only one of the processes happens to need the critical section at a given time), then the overhead of traditional locking may be eliminated.
- Synchronization can incur a large cost in modern out-of-order pipelined processors. A lock instruction is usually implemented as a serializing operation, which makes the operation expensive. In particular, a lock instruction may not execute speculatively, and in turn, this may impede the speculative execution of succeeding instructions (e.g. the critical section). This contributes to making the lock operation expensive. Modern software languages, such as Java, provide built-in support for multi-threaded programming, and thus synchronization may be a frequent operation in the programs written in these languages.
- In contrast, using the speculative execution capabilities of modern processors to effect synchronization among parallel processes may significantly improve performance, especially in well tuned software, where a high percentage of the locks on a critical section may be uncontended at runtime. Output resulting from the synchronized parallel processes is provided at 120. This output may be provided to one or more other processes in the data processing machine, or to another data processing machine.
-
FIG. 3 is a block diagram illustrating adata processing machine 300. Themachine 300 may be a uniprocessor machine or a multiprocessor machine. Themachine 300 may also employ various advanced processor architecture features, such as super-pipelining and/or hyperthreading. - The
machine 300 includes two or moreparallel processes 310 operating in an applications layer and/or an operating system of themachine 300. Additionally, themachine 300 includes a processor/processing system in hardware, which may be an out-of-order processor/processing system, that provides speculative execution of instructions. An out-of-order processor may include amemory sub-system 320 andexecution units 330. Thememory sub-system 320 may include a system bus, a bus interface unit, and a cache, which may be divided into an instruction cache and a data cache and/or into multiple levels (e.g., alevel 1 cache and alevel 2 cache). Thememory sub-system 320 also may include a memory interface unit and memory order buffer (MOB). Theexecution units 330 may include integer, floating point, and multimedia (e.g., Single Instruction, Multiple Data (SIMD)) execution units. - The out-of-order processor includes an in-
order front end 340 that obtains instructions, and an out-of-order execution engine 350 that re-orders the instructions received from the in-order front end 340 and provides speculative execution. The in-order front end may include a fetch-decode unit 342, aninstruction cache 344, and abranch prediction unit 346. The out-of-order execution engine 350 may include an out-of-orderexecution management unit 352, including at least one buffer (e.g., a reorder buffer), and an in-order retire-store unit 354. - In general, one or more fetch-decode units may pull instructions from a cache and decode these instructions before placing them in an execution management back end of the processor. Decoding the instructions may involve breaking up more complex instructions into smaller micro-instructions and/or translating instructions into larger macro-instructions, depending on the processor architecture. Moreover, the out-of-order
execution management unit 352 may include a dispatch-execute unit that checks instructions in a reorder buffer and processes those that have all the necessary information for execution. - The retire-
store unit 354 may inspect instructions in the out-of-orderexecution management unit 352. The retire-store unit 354 may remove completed instructions and store instruction results temporarily until they are sent back to a cache. The retire-store unit 354 also may receive completed instructions directly from a dispatch execute unit and/or theexecution units 330. - The out-of-order processor/processing system of the
machine 300 has an instruction set architecture (ISA) 360 including speculative execution control circuitry that handles at least one machine instruction that facilitates synchronization between parallel processes by exposing the processor speculation to program control. For example, two new instructions, a speculative execution instruction and a speculation termination instruction, can be added to the ISA of a processor having a mechanism to execute instructions speculatively. These two new instructions can then be used to implement synchronization. - The speculative execution (“spec”) instruction may take first and second operands (e.g., spec loc, addr), behave as a no-op if a memory location indicated by the first operand contains a non-zero value, cause the processor to speculatively execute additional instructions if the memory location contains a zero value, and cause the processor to start executing instructions from an address indicated by the second operand if a mis-speculation occurs. The nature of a mis-speculation during the speculative execution may depend in part on the processor architecture.
- The hardware may provide invalidation based cache coherence to detect memory dependence violation, such as may be implemented using a MOB in the
memory sub-system 320 and a snoop controller in a data cache unit. A processor/processing unit may maintain a queue of load addresses and snoop the bus to check whether any other processor/processing unit intends to write to a memory location that it has read. A memory dependency violation may be handled in the same way as a branch mis-prediction: the in-flight instructions may be flushed (e.g., any stores, or other changes caused to processor state by the in-flight instructions are discarded), and the processor may begin fetching from the mis-speculation address (e.g., the second operand of the spec instruction). Other approaches to detecting a memory dependency violation, and to starting execution from a different address if a misspeculation occurs, are also possible. - During the speculative execution, the processor may check for dependency violations, such as read-after-write (RAW) dependencies, to identify a mis-speculation. In a uniprocessor machine, an interrupt may be considered a mis-speculation, and thus, if a speculative instruction causes an interrupt, this may shoot down the speculation. For example, the machine hardware may keep track of clock interrupts, and a context switch in a uniprocessor implementation may be considered a mis-speculation. Moreover, multiple types of external events, such as DMA (Direct Memory Access) events, may also be treated as mis-speculation. In a multiprocessor implementation, memory dependency violations, interrupts, DMA events, etc. may all be treated as mis-speculation.
- The speculation termination (“commit”) instruction may cause the processor to begin retiring the additional instructions if the additional instructions have been speculatively executed. The commit instruction brings the processor out of the speculation mode initiated by the spec instruction, and while the processor is retiring the speculative instructions, the processor continues checking for a mis-speculation (e.g., an interrupt or a dependency violation) until the processor retires the commit instruction. If the processor detects a mis-speculation, it flushes any remaining speculative instructions, and starts executing instructions from the specified address. For example, the commit instruction may take first and second operands (e.g., commit loc, addr), behave as a no-op if a memory location indicated by the first operand contains a non-zero value, and cause the processor to start executing instructions from an address indicated by the second operand if a mis-speculation occurs while the processor is retiring the speculative instructions.
-
FIG. 5 illustrates anexample code section 500 implementing synchronization according to the new approach. By way of comparison, a conventional approach to implementing synchronization through an atomic read-modify-write of a memory location is as follows: -
volatile int lock_var; .... grab_lock: if(lock_var==0){ //denotes unlocked state lock; cmpxchg lock_var,0,tid; //atomic read-modify-write if(lock_var==tid){ //got the lock CS; //critical section lock_var=0; //unlock } else goto grab_lock; //try again } else goto grab_lock; //try again
The variable lock_var denotes the memory location, where Lock_var being equal to zero implies that the lock is currently free. Every process/thread in this example has a unique identifier that is given by the identifier tid. The cmpxchg is an atomic operation that compares the contents of the memory location with zero, and if the memory location equals zero, the operation then modifies the location to contain tid. - The new approach may convert the atomic read-modify-write into a speculative read-modify-write, as follows:
-
volatile int lock_var; // lock_var is the lock variable if(lock_var==0){ // this denotes unlocked state loc=0; spec loc, shoot_down; //begin speculation, goto shoot_down // if misspeculated rl=lock_var; // line 1if(rl==0){ // line 2lock_var=tid; //line 3 } commit loc,shoot_down; //start retiring, goto shootdown on // violation if(lock_var==tid){ //if true then got the lock CS; //critical section lock_var=0; //unlock goto post_lock; } shoot_down: //there was a conflict, do the usual // atomic operation grab lock the conventional way ... post_lock: normal program flow ...
If only one process/thread tries to grab the lock at any time, then the speculative read-modify-write (lines line 1 is a read from a memory location andline 3 is a write to the same memory location, thus causing a RAW dependence violation. The speculation is aborted, instructions from the shootdown label are fetched, and thus the processes/threads fall back upon the conventional method of grabbing the lock. - The syntax for the speculative execution instruction and the speculation termination instruction in this example is merely exemplary. The ‘loc’ (which denotes a memory location) in the commit syntax is used to identify the previously executed spec instruction. The commit forms a speculation block with the spec instruction that has the same value of ‘loc’ in this example. However, another syntax is also possible. For example, the commit instruction may have no operands, form a block with the previous spec instruction, and use the same shoot down address specified in the spec instruction.
-
FIG. 6 illustrates areorder buffer 600 as may be used in a processor that supports a speculative execution instruction and a speculation termination instruction. Thereorder buffer 600 includes ahead 610 and atail 620 of the instructions in the instruction pool. The instructions may be in the form of micro-ops or macro-ops. - The
reorder buffer 600 may include a to-be-retired (TBR) pointer 630 (pointing to the head instruction 610) and a can-be-retired (CBR)pointer 640. TheTBR pointer 630 indicates which instruction is being retired, and theCBR pointer 640 indicates which instructions have finished executing and can be retired. Thepointers reorder buffer 600. When thepointers TBR pointer 630 may be stopped from advancing until theCBR pointer 640 hits a speculation termination instruction. - Thus, the processor does not start retiring the first instruction in the speculative block until the last instruction, and all the intermediate instructions, have been executed and are ready to retire. As shown in the
reorder buffer 600, aspeculative execution instruction 610 has stopped theTBR pointer 630, theCBR pointer 640 points to acurrent instruction 650, and aspeculation termination instruction 670 has not yet been executed and cannot be executed until after anintermediate instruction 660 has been executed. Once theCBR pointer 640 reaches thespeculation termination instruction 670, then theTBR pointer 630 is free to advance, and the processor begins retiring instructions again. Mis-speculation checking continues while theTBR pointer 630 advances toward theCBR pointer 640. - As the
CBR pointer 640 scans the instructions in the block of instructions, the execution engine may identify any of the instructions in the block that may trigger a mis-speculation, for example an instruction that may raise an interrupt, and send a corresponding message to the front end of the processor. The entire speculative block of instructions (the instructions between the head and the tail of the ROB) may then be flushed from the pipeline, and a message to the in-order front-end may provide the address from where to begin fetching the new instructions to fill thereorder buffer 600. The circuitry used to implement this in the processor may be similar to that used in handling branch mis-prediction in current processors. - In a multiprocessor environment, a MOB may detect a memory violation and then communicate this to the front-end and the reorder buffer. This causes the in-flight instructions to be flushed and new instructions to be fetched from a different location. The MOB may keep a buffer that contains the addresses that have been read by the instructions in the reorder buffer in a first processor (the current in-flight non-retired instructions). If a different processor writes into any of these addresses, then the different processor may send an invalidation signal to the first processor to maintain cache coherency. The snoop controller in the first processor monitors the invalidation signals on the bus, and if the address of any of those signals matches any of the load addresses in the MOB, then the snoop controller/MOB sends a signal to the reorder buffer and the front-end that triggers mis-speculation and the consequent recovery.
- Referring again to
FIG. 5 , if the acquisition of the lock is uncontended, then the entire lock-check sequence (lines - If multiple processes/threads attempt to grab the lock at the same time, they will execute the speculative read-modify-write sequence (
line 1,line 2, and line 3). They will then execute the commit instruction and start retiring the speculative sequence. One process/thread, Ti, may be the first to commit the store instruction inline 3. This means that Ti will have done a successful request for ownership (RFO) for the cache line containing the variable lock_var, and invalidated copies with other processors. Because the first instruction (line 1) in the speculative sequence is a load of the same memory location, the store by Ti will cause a dependency violation in all the other processes/threads, and cause them to mis-speculate. Cache coherence enforces the fundamental property that stores to the same address are serialized. Thus, for stores to the same address by multiple processors, all the processors see the stores in some particular order, and all but one processor will be shot down due to the dependence violations. All other threads will branch to the code sequence in shoot_down and try to grab the lock by using the conventional atomic read-modify-write operation. -
FIG. 2 illustrates synchronization of parallel processes using processor speculation and cache coherence maintenance. Machine instructions, including a memory access instruction, are speculatively executed in a processing system to effect synchronization at 200. The speculatively executed machine instructions are retired at 210. Cache coherence is maintained in the processing system, during the speculative execution and the retiring of the instructions, to effect the synchronization between the parallel processes at 220. Any violation of cache coherence during the executing-retiring interval implies that synchronization was not successful. Conversely, if there was no violation, it implies that synchronization was successful. -
FIG. 4 is a block diagram illustrating a system including a multiprocessor. Adata processing machine 420 is communicatively coupled with one ormore information sources 410 through anetwork 400. Themachine 420 may include acommunication interface 430, avirtual machine 440, and amemory 450. In addition, themachine 420 includes amultiprocessor 460, which includes multiple processors/processing units 462. Themultiprocessor 460 employs the systems and techniques described, and may include multiple processing units on a single die or on multiple chips. - The
machine 420 may receive software via thenetwork 400 and send output to other data processing machines via thenetwork 400. Thevirtual machine 440 may translate software information indicative of instructions into one or more machine instructions that control speculative execution in themultiprocessor 460. For example, thevirtual machine 440 may be a Java virtual machine that translates multi-threaded Java code into machine instructions. In addition, one or moreenvironmental sensors 470 may be connected with the processor to provide information regarding the environment of themachine 420, such as in the case where themachine 420 is a remote monitoring station. - The systems and techniques described here represent a new programming paradigm for implementing synchronization. This new programming paradigm may offer significant processing speed advantages for multi-threaded programs. Although only a few embodiments have been described in detail above, other modifications are possible and readily apparent from the description herein.
- For example, a possible implementation of the spec instruction is to restrict the window of speculation to the reorder buffer size, and trigger a mis-speculation otherwise. If the CBR pointer reaches the TBR pointer, which implies that a commit instruction was not found inside the ROB, then a mis-speculation is triggered. The pipeline is flushed and the processor starts fetching from the mis-speculation address.
- Instead of two instructions, a single speculative instruction may be provided that commits after a certain number of speculative instructions, either a fixed number of instructions or an input number of instructions. An input number N may be in a third operand, which may correspond to N instructions to speculate. Other embodiments are also possible.
- In addition, the new instructions described can be used in other contexts as well. For example, they can be used for implementing non-faulting loads by putting the loads after the spec instruction. The semantics of the spec instruction ensures that the loads are committed only if they do not cause an interrupt/fault. Non-faulting loads can be used for software prefetching.
- The logic flows depicted in
FIGS. 1 and 2 do not require the particular order shown, sequential order, or that all operations illustrated be performed, to achieve desirable results. Other embodiments may be within the scope of the following claims.
Claims (20)
1. A processor comprising:
a front end that obtains instructions; and
a back end that provides speculative execution of the instructions;
wherein the processor includes an instruction set architecture and speculative execution control circuitry that handles at least one machine instruction that facilitates synchronization between parallel processes by exposing processor speculation of synchronization lock acquisition code to program control;
wherein the processor speculation checks for a dependency violation during acquisition of the synchronization lock.
2. The processor of claim 1 , wherein
the at least one machine instruction of the instruction set architecture comprises a speculative execution instruction and a speculation termination instruction,
the speculative execution instruction causes the processor to speculatively execute additional instructions, and
the speculation termination instruction causes the processor to begin retiring the additional instructions.
3. The processor of claim 2 , wherein the front end comprises an in-order front end, and the back end comprises an out-of-order execution engine, which re-orders the instructions, and an execution unit that perform the re-ordered instructions.
4. The processor of claim 3 , wherein the out-of-order execution engine comprises an out-of-order execution management unit, including at least one buffer, and an in-order retire-store unit.
5. The processor of claim 4 , wherein the at least one buffer comprises a reorder buffer.
6. The processor of claim 2 , wherein the front end comprises a fetch-decode unit and a branch prediction unit.
7. The processor of claim 2 , wherein the processor speculation checks for an interrupt during acquisition of the synchronization lock.
8. The processor of claim 2 , wherein the speculative execution instruction takes two operands, and the speculation termination instruction takes two operands.
9. A machine-implemented method comprising:
generating parallel processes in a data processing machine;
effecting synchronization between the parallel processes using processor speculation in the data processing machine to speculatively execute one or more instructions that read-modify-write a lock variable associated with a critical section; and
providing output resulting from the synchronized parallel processes.
10. The method of claim 9 , wherein said effecting synchronization comprises ending speculative execution of the one or more instructions that read-modify-write the lock variable before performing the critical section.
11. The method of claim 10 , wherein said effecting synchronization comprises placing in an out-of-order execution management unit of a processor, at least one machine instruction that limits when other machine instructions are retired from the out-of-order execution management unit.
12. The method of claim 11 , wherein said effecting synchronization comprises translating at least one high-level software instruction into at least one machine instruction that controls speculative execution in a processor.
13. The method of claim 12 , wherein said generating parallel processes comprises running a software program that spawns multiple threads in the data processing machine.
14. The method of claim 12 , wherein said providing output comprises sending the output to another data processing machine.
15. An article comprising a machine-readable storage medium embodying information indicative of instructions that when performed by one or more machines result in operations comprising:
generating parallel processes in a data processing machine;
effecting synchronization between the parallel processes using processor speculation in the data processing machine to speculatively execute one or more instructions that read-modify-write a lock variable associated with a critical section; and
providing output resulting from the synchronized parallel processes.
16. The article of claim 15 , wherein said effecting synchronization comprises ending speculative execution of the one or more instructions that read-modify-write the lock variable before performing the critical section.
17. The article of claim 16 , wherein said effecting synchronization comprises placing in an out-of-order execution management unit of a processor, at least one machine instruction that limits when other machine instructions are retired from the out-of-order execution management unit.
18. The article of claim 17 , wherein said effecting synchronization comprises translating at least one high-level software instruction into at least one machine instruction that controls speculative execution in a processor.
19. The article of claim 18 , wherein said generating parallel processes comprises running a software program that spawns multiple threads in the data processing machine.
20. The article of claim 18 , wherein said providing output comprises sending the output to another data processing machine.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US12/360,310 US20090138681A1 (en) | 2004-03-09 | 2009-01-27 | Synchronization of parallel processes |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/797,886 US7500087B2 (en) | 2004-03-09 | 2004-03-09 | Synchronization of parallel processes using speculative execution of synchronization instructions |
US12/360,310 US20090138681A1 (en) | 2004-03-09 | 2009-01-27 | Synchronization of parallel processes |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/797,886 Continuation US7500087B2 (en) | 2004-03-09 | 2004-03-09 | Synchronization of parallel processes using speculative execution of synchronization instructions |
Publications (1)
Publication Number | Publication Date |
---|---|
US20090138681A1 true US20090138681A1 (en) | 2009-05-28 |
Family
ID=34920151
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/797,886 Expired - Fee Related US7500087B2 (en) | 2004-03-09 | 2004-03-09 | Synchronization of parallel processes using speculative execution of synchronization instructions |
US12/360,310 Abandoned US20090138681A1 (en) | 2004-03-09 | 2009-01-27 | Synchronization of parallel processes |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/797,886 Expired - Fee Related US7500087B2 (en) | 2004-03-09 | 2004-03-09 | Synchronization of parallel processes using speculative execution of synchronization instructions |
Country Status (1)
Country | Link |
---|---|
US (2) | US7500087B2 (en) |
Cited By (14)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090024894A1 (en) * | 2007-07-18 | 2009-01-22 | International Business Machines Corporation | System and method for predicting iwarx and stwcx instructions in test pattern generation and simulation for processor design verification/validation in interrupt mode |
US20090024892A1 (en) * | 2007-07-18 | 2009-01-22 | Vinod Bussa | System and Method of Testing using Test Pattern Re-Execution in Varying Timing Scenarios for Processor Design Verification and Validation |
US20090024886A1 (en) * | 2007-07-18 | 2009-01-22 | Sampan Arora | System and Method for Predicting lwarx and stwcx Instructions in Test Pattern Generation and Simulation for Processor Design Verification and Validation |
US20090024873A1 (en) * | 2007-07-18 | 2009-01-22 | Sandip Bag | System and Method for Increasing Error Checking Performance by Calculating CRC Calculations After Multiple Test Patterns for Processor Design Verification and Validation |
US20090024876A1 (en) * | 2007-07-18 | 2009-01-22 | Sampan Arora | System and Method for Verification of Cache Snoop Logic and Coherency Between Instruction & Data Caches for Processor Design Verification and Validation |
US20090024877A1 (en) * | 2007-07-18 | 2009-01-22 | Shubhodeep Roy Choudhury | System and Method for Creating Different Start Cache and Bus States Using Multiple Test Patterns for Processor Design Verification and Validation |
US20100023697A1 (en) * | 2008-07-25 | 2010-01-28 | International Business Machines Corporation | Testing Real Page Number Bits in a Cache Directory |
US20120089813A1 (en) * | 2010-10-07 | 2012-04-12 | Jin Tai-Song | Computing apparatus based on reconfigurable architecture and memory dependence correction method thereof |
US8726252B2 (en) | 2011-01-28 | 2014-05-13 | International Business Machines Corporation | Management of conditional branches within a data parallel system |
US20170083340A1 (en) * | 2015-09-19 | 2017-03-23 | Microsoft Technology Licensing, Llc | Instruction block address register |
US9940136B2 (en) | 2015-06-26 | 2018-04-10 | Microsoft Technology Licensing, Llc | Reuse of decoded instructions |
US10346168B2 (en) | 2015-06-26 | 2019-07-09 | Microsoft Technology Licensing, Llc | Decoupled processor instruction window and operand buffer |
US10409606B2 (en) | 2015-06-26 | 2019-09-10 | Microsoft Technology Licensing, Llc | Verifying branch targets |
US11755484B2 (en) | 2015-06-26 | 2023-09-12 | Microsoft Technology Licensing, Llc | Instruction block allocation |
Families Citing this family (39)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20070006195A1 (en) * | 2004-03-31 | 2007-01-04 | Christof Braun | Method and structure for explicit software control of data speculation |
US7711928B2 (en) * | 2004-03-31 | 2010-05-04 | Oracle America, Inc. | Method and structure for explicit software control using scoreboard status information |
US7606983B2 (en) * | 2004-06-21 | 2009-10-20 | Nxp B.V. | Sequential ordering of transactions in digital systems with multiple requestors |
US8544020B1 (en) * | 2004-09-14 | 2013-09-24 | Azul Systems, Inc. | Cooperative preemption |
WO2007073611A1 (en) * | 2005-12-24 | 2007-07-05 | Intel Corporation | Method and apparatus for ordering code based on critical sections |
US8099538B2 (en) * | 2006-03-29 | 2012-01-17 | Intel Corporation | Increasing functionality of a reader-writer lock |
US8190859B2 (en) | 2006-11-13 | 2012-05-29 | Intel Corporation | Critical section detection and prediction mechanism for hardware lock elision |
US8037466B2 (en) | 2006-12-29 | 2011-10-11 | Intel Corporation | Method and apparatus for merging critical sections |
US8930680B2 (en) * | 2007-12-21 | 2015-01-06 | International Business Machines Corporation | Sync-ID for multiple concurrent sync dependencies in an out-of-order store queue |
US9170962B2 (en) * | 2007-12-21 | 2015-10-27 | International Business Machines Corporation | Dynamic designation of retirement order in out-of-order store queue |
US9928071B1 (en) | 2008-05-02 | 2018-03-27 | Azul Systems, Inc. | Enhanced managed runtime environments that support deterministic record and replay |
US10417051B2 (en) | 2008-05-23 | 2019-09-17 | International Business Machines Corporation | Synchronizing shared resources in an order processing environment using a synchronization component |
US8364902B2 (en) * | 2009-08-07 | 2013-01-29 | Via Technologies, Inc. | Microprocessor with repeat prefetch indirect instruction |
CN101882063B (en) * | 2009-08-07 | 2014-10-29 | 威盛电子股份有限公司 | Microprocessor and method for prefetching data to the microprocessor |
US8838906B2 (en) * | 2010-01-08 | 2014-09-16 | International Business Machines Corporation | Evict on write, a management strategy for a prefetch unit and/or first level cache in a multiprocessor system with speculative execution |
US8533399B2 (en) * | 2010-01-15 | 2013-09-10 | International Business Machines Corporation | Cache directory look-up re-use as conflict check mechanism for speculative memory requests |
US8751748B2 (en) * | 2010-01-15 | 2014-06-10 | International Business Machines Corporation | Reader set encoding for directory of shared cache memory in multiprocessor system |
US8418156B2 (en) * | 2009-12-16 | 2013-04-09 | Intel Corporation | Two-stage commit (TSC) region for dynamic binary optimization in X86 |
US20110276966A1 (en) * | 2010-05-06 | 2011-11-10 | Arm Limited | Managing task dependency within a data processing system |
US9449360B2 (en) | 2011-12-28 | 2016-09-20 | Intel Corporation | Reducing the number of sequential operations in an application to be performed on a shared memory cell |
US9823929B2 (en) | 2013-03-15 | 2017-11-21 | Qualcomm Incorporated | Optimizing performance for context-dependent instructions |
US9535744B2 (en) * | 2013-06-29 | 2017-01-03 | Intel Corporation | Method and apparatus for continued retirement during commit of a speculative region of code |
GB2519108A (en) | 2013-10-09 | 2015-04-15 | Advanced Risc Mach Ltd | A data processing apparatus and method for controlling performance of speculative vector operations |
GB2519107B (en) * | 2013-10-09 | 2020-05-13 | Advanced Risc Mach Ltd | A data processing apparatus and method for performing speculative vector access operations |
RU2644528C2 (en) | 2013-12-23 | 2018-02-12 | Интел Корпорейшн | Instruction and logic for identification of instructions for removal in multi-flow processor with sequence changing |
US10241958B2 (en) | 2014-08-29 | 2019-03-26 | Microsoft Technology Licensing, Llc | Configurable synchronized processing of multiple operations |
US9501284B2 (en) * | 2014-09-30 | 2016-11-22 | Apple Inc. | Mechanism for allowing speculative execution of loads beyond a wait for event instruction |
US10318292B2 (en) | 2014-11-17 | 2019-06-11 | Intel Corporation | Hardware instruction set to replace a plurality of atomic operations with a single atomic operation |
US10303525B2 (en) * | 2014-12-24 | 2019-05-28 | Intel Corporation | Systems, apparatuses, and methods for data speculation execution |
US10061583B2 (en) * | 2014-12-24 | 2018-08-28 | Intel Corporation | Systems, apparatuses, and methods for data speculation execution |
US10942744B2 (en) * | 2014-12-24 | 2021-03-09 | Intel Corporation | Systems, apparatuses, and methods for data speculation execution |
US9785442B2 (en) | 2014-12-24 | 2017-10-10 | Intel Corporation | Systems, apparatuses, and methods for data speculation execution |
US10061589B2 (en) | 2014-12-24 | 2018-08-28 | Intel Corporation | Systems, apparatuses, and methods for data speculation execution |
US10387158B2 (en) | 2014-12-24 | 2019-08-20 | Intel Corporation | Systems, apparatuses, and methods for data speculation execution |
US10387156B2 (en) | 2014-12-24 | 2019-08-20 | Intel Corporation | Systems, apparatuses, and methods for data speculation execution |
CN107408035B (en) * | 2015-03-27 | 2021-11-09 | 英特尔公司 | Apparatus and method for inter-strand communication |
US10437593B2 (en) * | 2017-04-27 | 2019-10-08 | Nvidia Corporation | Techniques for comprehensively synchronizing execution threads |
US20200372129A1 (en) * | 2018-01-12 | 2020-11-26 | Virsec Systems, Inc. | Defending Against Speculative Execution Exploits |
CN112631925A (en) * | 2020-12-29 | 2021-04-09 | 北京轩宇信息技术有限公司 | Method for detecting single variable atom violation defect |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5428807A (en) * | 1993-06-17 | 1995-06-27 | Digital Equipment Corporation | Method and apparatus for propagating exception conditions of a computer system |
US5913925A (en) * | 1996-12-16 | 1999-06-22 | International Business Machines Corporation | Method and system for constructing a program including out-of-order threads and processor and method for executing threads out-of-order |
US6009512A (en) * | 1997-10-27 | 1999-12-28 | Advanced Micro Devices, Inc. | Mechanism for forwarding operands based on predicated instructions |
US6230230B1 (en) * | 1998-12-03 | 2001-05-08 | Sun Microsystems, Inc. | Elimination of traps and atomics in thread synchronization |
US20030208673A1 (en) * | 2000-05-31 | 2003-11-06 | Shailender Chaudhry | Monitor entry and exit for a speculative thread during space and time dimensional execution |
-
2004
- 2004-03-09 US US10/797,886 patent/US7500087B2/en not_active Expired - Fee Related
-
2009
- 2009-01-27 US US12/360,310 patent/US20090138681A1/en not_active Abandoned
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5428807A (en) * | 1993-06-17 | 1995-06-27 | Digital Equipment Corporation | Method and apparatus for propagating exception conditions of a computer system |
US5913925A (en) * | 1996-12-16 | 1999-06-22 | International Business Machines Corporation | Method and system for constructing a program including out-of-order threads and processor and method for executing threads out-of-order |
US6009512A (en) * | 1997-10-27 | 1999-12-28 | Advanced Micro Devices, Inc. | Mechanism for forwarding operands based on predicated instructions |
US6230230B1 (en) * | 1998-12-03 | 2001-05-08 | Sun Microsystems, Inc. | Elimination of traps and atomics in thread synchronization |
US20030208673A1 (en) * | 2000-05-31 | 2003-11-06 | Shailender Chaudhry | Monitor entry and exit for a speculative thread during space and time dimensional execution |
Cited By (22)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7739570B2 (en) | 2007-07-18 | 2010-06-15 | International Business Machines Corporation | System and method for increasing error checking performance by calculating CRC calculations after multiple test patterns for processor design verification and validation |
US20090024886A1 (en) * | 2007-07-18 | 2009-01-22 | Sampan Arora | System and Method for Predicting lwarx and stwcx Instructions in Test Pattern Generation and Simulation for Processor Design Verification and Validation |
US7747908B2 (en) | 2007-07-18 | 2010-06-29 | International Business Machines Corporation | System and method for creating different start cache and bus states using multiple test patterns for processor design verification and validation |
US20090024873A1 (en) * | 2007-07-18 | 2009-01-22 | Sandip Bag | System and Method for Increasing Error Checking Performance by Calculating CRC Calculations After Multiple Test Patterns for Processor Design Verification and Validation |
US20090024876A1 (en) * | 2007-07-18 | 2009-01-22 | Sampan Arora | System and Method for Verification of Cache Snoop Logic and Coherency Between Instruction & Data Caches for Processor Design Verification and Validation |
US20090024877A1 (en) * | 2007-07-18 | 2009-01-22 | Shubhodeep Roy Choudhury | System and Method for Creating Different Start Cache and Bus States Using Multiple Test Patterns for Processor Design Verification and Validation |
US7647539B2 (en) | 2007-07-18 | 2010-01-12 | International Business Machines Corporation | System and method of testing using test pattern re-execution in varying timing scenarios for processor design verification and validation |
US20090024894A1 (en) * | 2007-07-18 | 2009-01-22 | International Business Machines Corporation | System and method for predicting iwarx and stwcx instructions in test pattern generation and simulation for processor design verification/validation in interrupt mode |
US8127192B2 (en) | 2007-07-18 | 2012-02-28 | International Business Machines Corporation | Predicting lwarx and stwcx instructions in test pattern generation and simulation for processor design verification/validation in interrupt mode |
US7689886B2 (en) | 2007-07-18 | 2010-03-30 | International Business Machines Corporation | System and method for predicting lwarx and stwcx instructions in test pattern generation and simulation for processor design verification and validation |
US7661023B2 (en) * | 2007-07-18 | 2010-02-09 | International Business Machines Corporation | System and method for verification of cache snoop logic and coherency between instruction & data caches for processor design verification and validation |
US20090024892A1 (en) * | 2007-07-18 | 2009-01-22 | Vinod Bussa | System and Method of Testing using Test Pattern Re-Execution in Varying Timing Scenarios for Processor Design Verification and Validation |
US8185694B2 (en) | 2008-07-25 | 2012-05-22 | International Business Machines Corporation | Testing real page number bits in a cache directory |
US20100023697A1 (en) * | 2008-07-25 | 2010-01-28 | International Business Machines Corporation | Testing Real Page Number Bits in a Cache Directory |
US20120089813A1 (en) * | 2010-10-07 | 2012-04-12 | Jin Tai-Song | Computing apparatus based on reconfigurable architecture and memory dependence correction method thereof |
US8726252B2 (en) | 2011-01-28 | 2014-05-13 | International Business Machines Corporation | Management of conditional branches within a data parallel system |
US11755484B2 (en) | 2015-06-26 | 2023-09-12 | Microsoft Technology Licensing, Llc | Instruction block allocation |
US9940136B2 (en) | 2015-06-26 | 2018-04-10 | Microsoft Technology Licensing, Llc | Reuse of decoded instructions |
US10346168B2 (en) | 2015-06-26 | 2019-07-09 | Microsoft Technology Licensing, Llc | Decoupled processor instruction window and operand buffer |
US10409606B2 (en) | 2015-06-26 | 2019-09-10 | Microsoft Technology Licensing, Llc | Verifying branch targets |
US20170083340A1 (en) * | 2015-09-19 | 2017-03-23 | Microsoft Technology Licensing, Llc | Instruction block address register |
US10095519B2 (en) * | 2015-09-19 | 2018-10-09 | Microsoft Technology Licensing, Llc | Instruction block address register |
Also Published As
Publication number | Publication date |
---|---|
US7500087B2 (en) | 2009-03-03 |
US20050204119A1 (en) | 2005-09-15 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US7500087B2 (en) | Synchronization of parallel processes using speculative execution of synchronization instructions | |
US7882339B2 (en) | Primitives to enhance thread-level speculation | |
US8301849B2 (en) | Transactional memory in out-of-order processors with XABORT having immediate argument | |
EP2503460B1 (en) | Hardware acceleration for a software transactional memory system | |
US7930695B2 (en) | Method and apparatus for synchronizing threads on a processor that supports transactional memory | |
US7330963B2 (en) | Resolving all previous potentially excepting architectural operations before issuing store architectural operation | |
US6484254B1 (en) | Method, apparatus, and system for maintaining processor ordering by checking load addresses of unretired load instructions against snooping store addresses | |
US7529914B2 (en) | Method and apparatus for speculative execution of uncontended lock instructions | |
US8180977B2 (en) | Transactional memory in out-of-order processors | |
US6463511B2 (en) | System and method for high performance execution of locked memory instructions in a system with distributed memory and a restrictive memory model | |
TWI448897B (en) | Method and apparatus for monitoring memory access in hardware,a processor and a system therefor | |
US10019263B2 (en) | Reordered speculative instruction sequences with a disambiguation-free out of order load store queue | |
US9904552B2 (en) | Virtual load store queue having a dynamic dispatch window with a distributed structure | |
US9965277B2 (en) | Virtual load store queue having a dynamic dispatch window with a unified structure | |
EP2862063B1 (en) | A lock-based and synch-based method for out of order loads in a memory consistency model using shared memory resources | |
EP2862058B1 (en) | A semaphore method and system with out of order loads in a memory consistency model that constitutes loads reading from memory in order | |
US9990198B2 (en) | Instruction definition to implement load store reordering and optimization | |
US10545765B2 (en) | Multi-level history buffer for transaction memory in a microprocessor | |
US10255071B2 (en) | Method and apparatus for managing a speculative transaction in a processing unit | |
US7975129B2 (en) | Selective hardware lock disabling |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTEL CORPORATION, CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:SAHA, BRATIN;REEL/FRAME:022171/0309 Effective date: 20040309 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |