TWI512448B - Instruction for enabling a processor wait state - Google Patents

Description

Instruction to enable processor wait state Technical field of invention

The present invention is directed to instructions for enabling a processor wait state.

Technical background of the invention

As processor technology evolves, processors with more cores are also available. In order to execute software efficiently, the cores are assigned to different threads that can perform a single application. This configuration is called cooperative thread software. In modern cooperative thread software, it is quite common to have one thread wait for another thread to complete. Conventionally, a processor with a waiting thread executing is using active power while waiting. Again, the latency may be uncertain, and thus the processor may not be aware of how long it will wait.

Another mechanism that allows a core to wait is to place the core in a wait state, such as a low power state. In order to carry out this task, an operating system (OS) will be evoked. The OS can execute a pair of instructions, called a MONITOR instruction and a MWAIT instruction. It should be noted that these instructions are not available to the application hierarchy software. Conversely, these instructions can only be used in the OS privilege hierarchy to set an address range for monitoring and to put the processor into a low power state until the monitored address range is updated. However, there is considerable redundancy in the process of entering the OS to execute the instructions. This redundant operation takes the form of a high latency period and further complicates the complexity, because when the waiting thread exits from the wait state, the OS scheduling issue may cause the waiting thread to become the next one. Schedule thread.

Summary of the invention

In accordance with an embodiment of the present invention, a processor is specifically provided comprising: a core comprising a decoding logic component for receiving and decoding an instruction from a first application, the instruction specifying a watch to be monitored An identification data of a location and a timer value, the core and a timer coupled to the decoding logic component for counting the timer value; and a power management unit coupled to the core for Determining, based at least in part on the timer value, a type of low power state for the processor, and if the value of the monitored position is not equal to a target value and the timer value has not exceeded, the power The management unit is responsive to this determination to cause the processor to enter the low power state without the intervention of an operating system (OS).

Brief description of the schema

Figure 1 shows in a flow chart a method in accordance with an embodiment of the present invention.

Figure 2 is a flow chart showing a test that can be performed for a target value in accordance with an embodiment of the present invention.

Figure 3 is a block diagram showing a processor core in accordance with an embodiment of the present invention.

Figure 4 is a block diagram showing a processor in accordance with an embodiment of the present invention.

Figure 5 is a block diagram showing a processor in accordance with another embodiment of the present invention.

Figure 6 is a flow chart showing the interaction between a plurality of cooperative threads in accordance with an embodiment of the present invention.

Figure 7 is a block diagram showing a system in accordance with an embodiment of the present invention.

Detailed description of the preferred embodiment

In various embodiments, a user hierarchy instruction (in other words, an application level instruction) may be provisioned and used to allow an application to wait for one or more conditions to occur. While the application is waiting, a processor (eg, a core of a multi-core processor) on which the application is executing may be placed in a low power state, or the processor may switch to perform another execution. thread. Although the scope of the present invention is not limited thereto, the condition that the processor can wait may include detecting a value, a timeout of a timer, receiving an interrupt signal, etc., for example, receiving an interrupt signal from another processor. .

Accordingly, an application can wait for one or more operations to occur, for example, in another thread without succumbing to an operating system (OS) or other supervisory software. Moreover, based on the instruction information provided by the instruction, the wait state can occur in a time-dependent manner to enable the processor to select an appropriate low power state to enter. In other words, the control logic component of the processor itself can determine an appropriate low power state to enter based on the prepared instruction information and various different calculations performed in the processor. Therefore, redundant work that needs to be tied to the OS to enter a low power state can be avoided. It should be noted that the processor does not need to wait for another peer processor, but can wait for a total of processors, such as a floating point coprocessor or other fixed function device.

In various embodiments, a user hierarchy instruction can have various different information associated therewith, including a location to be monitored, a value to look for, and a timeout value. Although the scope of the present invention is not limited thereto, this user hierarchy instruction may be referred to as a processor wait instruction for the convenience of discussion. Different styles of such user-level instructions may be provided, each of which may, for example, indicate waiting for a particular value, set of values, range, or cause the wait to be connected to an operation, for example, incrementing a counter when the value is true the amount.

In general, a processor may cause various actions to occur in response to a processor waiting for an instruction, the instruction may include the following instruction information or associated with the following instruction information: a source field indicating one of the tests to be tested The position of the value; a timeout or expiration timer value indicating a point in time at which the wait state should end (if the value to be tested is not reached); and a result field indicating the value to be obtained . In other applications, in addition to the fields, a destination or mask field may exist in an implementation where the source value is masked and tested for a predetermined value (eg, regardless of the mask) Whether the resulting mask value is non-zero).

As described above, the processor can perform various different operations in response to this instruction. In general, the operations may include: testing whether a value of the monitored position is a target value (eg, performing a Boolean operation to test a true 〞 condition); and testing whether the deadline has been reached. The value of the device. If one of these conditions is not met (eg, true), or if an interrupt is received from another entity, the instruction can be completed. Otherwise, you may want to start an organization to monitor the location to see if the value will change. Therefore, at this time, a waiting state can be entered. In this wait state, the processor can enter a low power state or can initiate an action of another processor hardware thread. If a low power state is desired, the processor can select an appropriate low power state based, at least in part, on the length of time remaining until the deadline timer. The low power state can then be entered and the processor can remain in this state until waking up by one of the aforementioned conditions. Although described in terms of such general operations, it is to be understood that various features and operations may be present in different ways in different implementations.

Referring now to Figure 1, a flowchart is shown in accordance with an embodiment of the present invention. As shown in FIG. 1, method 100 can be performed by a processor executing a user hierarchy command to control a processor to wait for operation. As can be seen, method 100 can begin by decoding a received instruction (block 110). For example, the command can be a user-level instruction prepared by an application, such as an application implemented by using multiple threads, each of which includes a cooperative thread application that can be executed with the execution thread. Actions have some sort of interdependent instruction. After decoding the instruction, the processor can load a memory value into a cache memory and a scratchpad (block 120). More specifically, a source of operands of the instruction can identify a location, such as a memory that can take a value above. This value can be loaded into a cache memory, such as a low level cache memory associated with the core that is executing the instruction, such as a private cache memory. Furthermore, the value can be stored in a register of the core. As an example, the scratchpad can be a general purpose register for one of the threads of the logic processor. Next, the control action proceeds to block 130. In block 130, a deadline may be calculated in response to the instruction information. More specifically, if a condition is not met (eg, a desired value is not updated), this period may be the period of time that the waiting state should occur. In an embodiment, the instruction format may include information providing a deadline timer value. In order to determine the appropriate time to reach this deadline, in some implementations, the received deadline timer value and a current time counter value present in the processor, such as a timestamp counter (TSC) value, may be compared. . In some embodiments, this difference can be loaded into a deadline timer that can be implemented using a counter or register. In an embodiment, the deadline timer can be a countdown timer that begins counting down. In this implementation, the deadline is subtracted from the current TSC value and the countdown timer is active for the plurality of cycles. When the TSC value exceeds the deadline, it triggers the recovery action of the processor. In other words, as will be discussed below, when the deadline timer is decremented to zero, the wait state can be terminated if it is still being performed at that time. In a register implementation, a comparator can compare the value of the TSC counter and the duration in each cycle.

The above operation can thus appropriately set various different structures to be accessed and tested in the waiting state. Therefore, it is possible to enter a waiting state. This wait state can be substantially a portion of loop 155 that can be executed repeatedly until one of a plurality of conditions occurs. As can be seen, it can be determined whether a target value from the command information matches the value stored in the register (decision block 140). In an implementation in which the instruction information includes the target value, the data retrieved from the memory and stored in the register can be tested to determine if its value matches the target value. If so, the condition has not been met and the control action proceeds to block 195 where the action to execute the wait instruction can be completed. This action of completing the instruction may additionally set various different flags or other values so as to indicate an indication of the reason for exiting the waiting state. Once the instruction is completed, the operation of the thread requesting the wait state can continue.

Conversely, if it is determined in decision block 140 that the condition has not been met, the control action proceeds to decision block 150 where it can be determined if the deadline has been generated. If so, the instruction is completed in the above manner. Otherwise, control proceeds to decision block 160 where it can be determined if another hardware component is seeking to wake up the processor. If so, the instruction is completed in the above manner. Otherwise, control proceeds to block 170 where a low power state can be determined based at least in part on the deadline timer value. In other words, the processor itself can determine an appropriate low power state based on the time remaining before the deadline will occur and in a manner that does not require OS intervention. To achieve this determination, in some embodiments, one of the processors may be a non-core logical component. This logic component can include a chart or can be associated with a chart that links various different low power state and deadline timer values, as described below. Based on the result of this determination in block 170, the processor can enter a low power state (block 180). In this low power state, the various different configurations of the processor can be placed in a low power state, i.e., a core and other components on which the instructions are executed. The particular structure to be placed in a low power state and the level of the low power state may vary depending on the implementation. It should be noted that if the loop is crossed because an updated value is not the target value, a new low power state can be determined based on the updated deadline timer value, because if only a limited time remains, A certain low power state (eg, a deep sleep state) may be inappropriate.

Various different events can occur that cause the core to exit the low power state. It is noted that the low power state can be executed if the cached data (i.e., corresponding to the monitored location) has been updated (decision block 190). If so, the control action will return to decision block 140. Similarly, if the deadline expires and/or a wake-up signal is received from another hardware component, the control action can proceed from the low power state to one of decision blocks 150 and 160. Although the present invention has been exhibited in such a high-level embodiment in the embodiment of Fig. 1, it is to be understood that the scope of the invention is not limited thereto.

In other implementations, a masked test for a target value can occur. In other words, the user hierarchy instruction may implicitly represent a target value to be acquired. For example, the target value can be one of a masking operation between one source value from memory and one mask value in one of the source/destination operands of the instruction. Non-zero value. In one embodiment, the user hierarchy instruction can be a load, a mask, a wait, if it is a zero (LDMWZ) instruction of a processor ISA. In an embodiment, the instructions may be in the format of LDMWZ r32/64, M32/64. In this format, the first operand (r32/64) can store a mask, and the second operand (M32/64) can identify a source value (ie, the monitored location). In turn, a timeout value can be stored in a third register. For example, the deadline can be in an implicit register. In particular, these EDX:EAX registers can be used, which are the same set of registers that are written when the TSC counter is read. In general, the command can perform a non-busy polling of a signal value and enter a low power wait state if the signal is not available. In different implementations, it is possible to control both the bit signal and the count signal, where zero means that no item is waiting. The timeout value may indicate the length of time that the processor should wait for a non-zero result TSC cycle period before unconditionally restoring the operation. In one embodiment, the software may be provisioned via a memory mapping register (eg, a configuration and state register (CSR)) for information on which physical processors are in a low power state.

In this embodiment, the LDMWZ instruction will load the data from the source memory location, mask it with the source/destination value, and test to confirm if the resulting value is zero. If the mask value is not zero, the value loaded from the memory is placed in the unmasked source/destination register. Otherwise, the processor will enter a low power wait state. It should be noted that this low power state may or may not correspond to a currently defined low power state, such as the so-called C- according to the Advanced Configuration and Power Interface (ACPI) Specification Version 4 (published on June 16, 2009). status. The processor can be maintained in a low power state until a specified time interval expires, signaling a signal indicating an external exception (eg, general interrupt (INTR), non-mask interrupt (NMI), or system management interrupt (SMI)), Or write the source memory location with a value that is non-zero when masked. As part of entering this wait state, the processor can clear a Memory Map Register (CSR) bit indicating that the processor is currently waiting.

The non-zero value indicator of a flag register can be cleared and the non-zero value indicator of a flag register can be cleared because a value that would generate a non-zero value when masked is written to the monitored position and exits from the wait state. The masked value read is placed in the destination scratchpad. If the expiration condition of the timer causes an exit from the low power state, the zero value indicator of the flag register can be set to allow the software to detect the condition. If an exit condition occurs due to an external exception, the state of the processor and memory will cause the instruction to not be considered to have been executed. Therefore, the same LDMWZ instruction will be executed again when returning to the normal execution flow.

Referring now to Figure 2, a flow chart showing a test for a target value in accordance with another embodiment of the present invention is shown. As shown in FIG. 2, method 200 can begin by loading source data into a first register (block 210). The source material can be masked by a mask appearing in a second register (block 220). In various embodiments, the first and second registers may be specified by an instruction and may correspond to locations for storing the source and destination data, respectively. It can then be determined if the result of the masking operation is zero (decision block 230). If so, the desired condition has not been met and the processor can enter a low power state (block 240). Otherwise, the source data can be stored in the second register (block 250) and the instruction execution action is complete (block 260).

In the wait state, the target location will be updated, as determined in decision block 265, the control action will return to block 220 to perform the masking operation. If it is determined that another condition has occurred in the wait state (as determined by decision block 270), then control proceeds to block 260 for completion of the command. Although the present invention has been exhibited in such a high-level embodiment in the embodiment of Fig. 2, it is to be understood that the scope of the invention is not limited thereto.

Referring now to FIG. 3, a block diagram illustrates a processor core in accordance with an embodiment of the present invention. As shown in FIG. 3, processor core 300 can be a multi-stage pipelined out-of-order processor. In FIG. 3, processor core 300 is shown in a relatively simplified view to illustrate various different features in connection with processor wait state usage in accordance with an embodiment of the present invention.

As shown in FIG. 3, core 300 includes a front end unit 310 that can be used to retrieve instructions to be executed and to prepare the instructions for subsequent use in the processor. For example, the front end unit 310 can include a capture unit 301, an instruction cache 303, and an instruction decoder 305. In some implementations, the front end unit 310 can further include a stitch cache memory, and a microcode storage body and a micro operation storage body. The capture unit 301 can retrieve macro instructions, such as memory 303 from memory or instructions, and feed the instructions to the instruction decoder 305 to decode them into primitives, ie, micro-processors for execution by the processor. operating. According to an embodiment of the invention, the instruction to be managed in the front end unit 310 may be a user hierarchy processor waiting for an instruction. This instruction may enable the front end unit to access various different micro operations such that the operations can be performed, such as the multiple operations associated with the wait instruction above.

Coupled between front end unit 310 and execution unit 320 is an out of order (OOO) engine 315 that can be used to receive the microinstructions and prepare the instructions for execution. More specifically, the OOO engine 315 can include a variety of different buffers for reordering the microinstruction flow and configuring the various different resources required for execution, and in various different scratchpad archives (eg, the scratchpad archive 330) And the act of renaming the logical scratchpad is provided at a storage location in the extended scratchpad file 335). The scratchpad file 330 can include separate scratchpad files for integer and floating point operations. The extended scratchpad file 335 can provide a bank for vector size units, such as 256 or 512 bits per register.

A variety of different resources may be present in execution unit 320, including, for example, various different integers, floating point, and single instruction multiple data (SIMD) logic component units, as well as other specialized hardware. For example, the execution units may include one or more operational logic units (ALUs) 322. Additionally, there may be a wake-up logic component 324 in accordance with an embodiment of the present invention. The wake-up logic component can be used to perform some of the operations associated with performing a processor wait mode in response to a user hierarchy instruction. As discussed further below, other logic components to manage these wait states may exist in another portion of a processor, such as a non-core. Also shown in Figure 3 is a set of timers 326. The associated timer for analysis herein includes a TSC timer and a deadline timer that can be set by a value corresponding to a deadline, and if not in any other condition, the processor will Leave the wait state before the deadline. When the deadline timer reaches a predetermined count value (which may be a countdown to zero action in some embodiments), the wake logic component 324 may initiate certain operations. The result can be provided to a reclaim logic component, a reorder buffer (ROB) 340. More specifically, ROB 340 can include a variety of different arrays and logic components to receive information associated with the executed instructions. This information is then viewed by the ROB 340 to determine whether the instructions can be effectively retrieved and submitted to the processor's architectural status, or whether there are one or more instances that prevent proper retraction of the instructions. abnormal. Of course, the ROB 340 can take over other operations associated with the retract action. In a context in which the processor waits for an instruction in accordance with an embodiment of the present invention, the retracting action may cause the ROB 340 to set the state of one or more indicators of a flag register or other state register, which may indicate a The reason the processor exits a wait state.

As shown in FIG. 3, the ROB 340 is coupled to the cache memory 350, which in one embodiment may be a low-level cache memory (eg, an L1 cache memory), although the scope of the present invention is not Limited by this. Likewise, execution unit 320 can be directly coupled to cache memory 350. As can be seen, the cache memory 350 includes a watch engine 352 that can be assembled to monitor a particular cache line, ie, a monitored location, and when the value is updated, when in the cache line A wakeup logic component 324 (and/or a non-core component) may be provided with a feedback when a change occurs in the cache coherency state and/or when the cache line is lost. The watch engine 352 takes a given row and maintains it in a shared state. If the watch engine 352 has lost the cache line from the shared state, it will wake up the processor. From the cache memory 350, data communication can be performed by a higher level of cache memory, system memory, and the like. Although the present invention has been described in the embodiment of Fig. 3 in such a high-level embodiment, it is to be understood that the scope of the invention is not limited thereto.

Referring now to Figure 4, a block diagram illustrates a processor in accordance with an embodiment of the present invention. As shown in FIG. 4, the processor 400 may be a multi-core processor comprising a plurality of core 410 _a to 410 _n. In an embodiment, each such core may be grouped as core 300 as described above with reference to FIG. The various cores can be coupled via interconnect 415 to a non-core 420 that includes a variety of different components. As can be seen, the non-core 420 can include a shared cache 430, which can be a last-level cache memory. Additionally, the non-cores can include an integrated memory controller 440, various different interfaces 450, and a power management unit 455. In various embodiments, at least some of the functionality associated with executing a processor wait instruction may be implemented in power management unit 455. For example, based on information received with the instruction, such as the expiration timer value, power management unit 455 can determine an appropriate low power state in which a given core that is executing the wait instruction is placed in this state. In an embodiment, power management unit 455 can include a chart that correlates the timer value to a low power state. Unit 455 can look up the chart based on the determined deadline value associated with an instruction and select a corresponding wait state. In turn, power management unit 455 can generate a plurality of control signals to cause various different components, namely a given core and other processor units, to enter a low power state. As can be seen, the processor 400 can communicate with the system memory 460 via a memory bus. In addition, through the interface 450, it is possible to connect with various different under-wafer components, such as peripheral devices, bulk storage, and the like. Although the present invention has been shown in a specific embodiment in the embodiment of Fig. 4, it is to be understood that the scope of the invention is not limited thereto.

In other embodiments, a processor architecture may include an analog feature such that the processor can execute a first ISA instruction, referred to as a source ISA, wherein the architecture is referred to as a target ISA according to a second ISA. . In general, the soft system including both the OS and the application is compiled into the source ISA, and the hardware will specifically design the target for a given hardware implementation with special performance and/or energy efficiency characteristics. ISA.

Referring now to Figure 5, a block diagram illustrates a processor in accordance with another embodiment of the present invention. As shown in FIG. 5, system 500 includes a processor 510 and a memory 520. The memory 520 includes a conventional memory 522 that holds both the system and the application software, and a covert memory 524 that holds software for the target ISA. As can be seen, the processor 510 includes a simulation engine 530 that converts the source code into a target code. The simulation action can be done by interpretation or binary translation. Interpretation is usually used for the code it first encounters. Subsequently, because of the frequent execution of code regions (eg, hotspots) via dynamic feature studies, they are translated into the target ISA and stored in a code cache of hidden memory 524. The optimized actions are done as part of the translation process, and the code that is used quite often is subsequently further optimized. The translated code blocks will be maintained in the code cache 524 so that they can be used repeatedly.

Still referring to FIG. 5, the processor 510, which may be a core of a multi-core processor, may include a program counter 540 that provides an instruction pointer address to the instruction cache (I-cache memory) 550. . As can be seen, the I-cache memory 550 can additionally receive the target ISA instructions from the covert memory portion 524 that do not reach a given instruction address. Thus, I-cache memory 550 can store target ISA instructions that can be provided to decoder 560, which is one of the target ISA decoders, to receive incoming instructions at the macro instruction level and convert the instructions into micro The instructions are for execution in processor pipeline 570. Although the scope of the present invention is not limited in this regard, the pipeline 570 can be a separate pipeline including various stages for executing and retracting instructions. Various different execution units, timers, counters, storage locations and monitors as described above may be located in pipeline 570 to perform a processor wait instruction in accordance with an embodiment of the present invention. In other words, even though the processor 510 is in an implementation different from one of the microarchitectures that provide a user hierarchy processor to wait for instructions, the instructions can be executed on the base hardware.

Referring now to Figure 6, a flow chart illustrates the interaction between cooperative threads in accordance with an embodiment of the present invention. As shown in FIG. 6, method 600 can be used to execute multiple threads, such as in a multi-thread processor. In the context of Figure 6, two threads, thread 1 and thread 2, are a single application and can be interdependent, so the data to be used by a thread must first be subjected to the second execution. Update. Thus, as can be seen, thread 1 can receive a processor wait instruction during its execution (block 610). In the course of executing this wait instruction, it may be determined whether a test condition has been met (decision block 620). If not, the thread can enter a low power state (block 630). Although not shown in Figure 6, it is to be understood that this state can be exited when one of various conditions occurs. Conversely, if it is determined that the test condition has been met, the control action will proceed to block 640 where the code execution action may continue in the first thread. It should be noted that the test condition can refer to a monitored location to indicate when the second thread has successfully completed an update. Therefore, the test condition is not met before the execution of the code shown in reference thread 2, and the processor will enter a low power state.

Still referring to FIG. 6, regarding thread 2, it can execute a code that is interdependent with the first thread (block 650). For example, the second thread can execute a code for updating one or more values, the value being used to execute the first thread. To ensure that the first thread performs the action using the updated values, the application can be written to cause the first thread to enter the low power state until the data is updated by the second thread. . Therefore, during execution of the second thread, it can be determined whether it has completed the execution of the interdependent code (decision block 660). If not, you can continue to rely on the execution of the code. Conversely, if the interdependent code segment has been completed, control will proceed to block 670 where a predetermined value can be written to the monitored location (block 670). For example, the predetermined value may correspond to a test value associated with the processor waiting for an instruction. In other embodiments, the predetermined value can be a value such that when masked or used as a mask (having a value in the monitored position), the result is not zero, indicating that the The condition is tested and the first thread can continue to execute. Still referring to thread 2, after writing the predetermined value, the code execution action of the second thread can continue (block 680). Although the present invention has been shown in a specific embodiment in the embodiment of Fig. 6, it is to be understood that the scope of the invention is not limited thereto.

Thus, embodiments of the present invention can enable a lightweight corruption mechanism that allows a processor to delay waiting for one or more predetermined conditions to occur without the intervention of the OS. There is no need for an application to patrol a signal/value to become true in a loop, including causing the processor to consume power and preventing other threads from using the cycles in a hyper-thread machine. Test, abort, and jump operations. Therefore, it is possible to avoid OS monitoring actions in both redundant work and scheduling restrictions (the waiting application may not be the next thread of the schedule). Therefore, lightweight communication can occur between multiple cooperative threads. Further, a processor can flexibly select a sleep state according to time parameters that the user has indicated.

Embodiments of the invention may be implemented in a variety of different types of systems. Referring now to Figure 7, a block diagram illustrates a system in accordance with an embodiment of the present invention. As shown in FIG. 7, multiprocessor system 700 is a point-to-point interconnect system and includes a first processor 770 and a second processor 780 coupled via a point-to-point interconnect 750. As shown in FIG. 7, processor 770 and processor 780 can each be a multi-core processor, including a first processor core and a second processor core (ie, processor core 774a and processor core 774b and processor core 784a and processor core 784b), although more cores may potentially be located in the processors. The processor cores can execute a variety of different instructions, including a user hierarchy processor waiting for instructions.

Still referring to FIG. 7, the first processor 770 further includes a memory controller hub (MCH) 772 and a point-to-point (P-P) interface 776 and a point-to-point (P-P) interface 778. Similarly, second processor 780 includes MCH 782 and P-P interface 786 and P-P interface 788. As shown in FIG. 7, MCH 772 and MCH 782 couple the processors to individual memories, namely memory 732 and memory 734, which are locally attached to the main memory of the individual processors. (eg, a dynamic random access memory (DRAM)). First processor 770 and second processor 780 can be coupled to chip set 790 via P-P interconnect 752 and P-P interconnect 754, respectively. As shown in FIG. 7, the chip set 790 includes a P-P interface 794 and a P-P interface 798.

Moreover, chipset 790 includes an interface 792 for coupling wafer set 790 to high performance graphics engine 738 via P-P interconnect 739. In turn, wafer set 790 can be coupled to first bus bar 716 via interface 796. As shown in FIG. 7, various input/output (I/O) devices 714 can be coupled to the first bus bar 716, along with the bus bar bridge 718, which couples the first bus bar 716 to the second bus bar 720. . A variety of different devices can be coupled to the second bus 720, including, for example, a keyboard/mouse 722, a communication device 726, and a data storage unit 728, such as a disc drive or other mass storage device, which in one embodiment can include a program Code 730. Further, the audio I/O 724 can be coupled to the second bus 720.

Embodiments of the present invention can be implemented in a code and can be stored on a storage medium having stored thereon instructions that can be used to plan a system to execute the instructions. The storage medium may include, but is not limited to, any type of disc, including floppy discs, optical discs, solid state drive (SSD), compact disc read only memory (CD-ROM), rewritable compact disc (CD) -RW), and magneto-optical discs; semiconductor devices such as read-only memory (ROM), random access memory (RAM) such as dynamic random access memory (DRAM), static random access memory (SRAM) Erasable, programmable read-only memory (EPROM), flash memory, electrically erasable programmable read-only memory (EEPROM); magnetic or optical card, or any other suitable for storing electronic instructions Type media.

Although the invention has been described with reference to a limited number of embodiments, those skilled in the art will recognize various modifications and variations. It is intended that the following claims are intended to cover such modifications and alternatives

100, 200, 600. . . method

110~195, 210~270, 610~680. . . Step block

300, 774a-b, 784a-b. . . Processor core

301. . . Capture unit

303. . . Indicating cache memory

305. . . Indicating decoder

310. . . Front end unit

315. . . Out of order (OOO) engine

320. . . Execution unit

322. . . Arithmetic logic unit (ALU)

324. . . Wake up logic component

326. . . Timer

330. . . Scratch file

335. . . Extended register file

340. . . Reordering buffer (ROB)

350. . . Cache memory

352. . . Monitor engine

400, 510. . . processor

410 _an . . . core

415. . . Interconnect

420. . . Non-core

430. . . Shared cache memory

440. . . Integrated memory controller

450a-n, 792, 796. . . interface

455. . . Power management unit

460. . . System memory

500. . . system

520, 732~734. . . Memory

522. . . Traditional memory

524. . . Covert memory

530. . . Simulation engine

540. . . Program counter

550. . . Indicates cache memory (I-cache memory)

560. . . decoder

570. . . Processor pipeline

700. . . Multiprocessor system

714. . . Input/output (I/O) device

716. . . First bus

718. . . Bus bar bridge

720. . . Second bus

722. . . Keyboard/mouse

724. . . Audio I/O

726. . . Communication device

728. . . Data storage unit

730. . . Code

738. . . High performance graphics engine

739, 752~754. . . Point-to-point (P-P) interconnect

750. . . Point-to-point interconnect

770. . . First processor

772,782. . . Memory Controller Hub (MCH)

776~778, 786~788, 794, 798. . . Point-to-point (P-P) interface

780. . . Second processor

790. . . Chipset

Figure 1 shows in a flow chart a method in accordance with an embodiment of the present invention.

Figure 2 is a flow chart showing a test that can be performed for a target value in accordance with an embodiment of the present invention.

Figure 3 is a block diagram showing a processor core in accordance with an embodiment of the present invention.

Figure 4 is a block diagram showing a processor in accordance with an embodiment of the present invention.

Figure 5 is a block diagram showing a processor in accordance with another embodiment of the present invention.

Figure 6 is a flow chart showing the interaction between a plurality of cooperative threads in accordance with an embodiment of the present invention.

Figure 7 is a block diagram showing a system in accordance with an embodiment of the present invention.

100. . . method

110~195. . . Step block

Claims (24)

A processor comprising: a core comprising decoding logic and a timer, the decoding logic component for receiving and decoding instructions from a first application for specifying identification and timing of a location to be monitored And a timer coupled to the decoding logic for counting the timer value; and a power management unit coupled to the core to determine the processing based at least in part on the timer value The type of low power state in which the plurality of low power states are to enter, and if the value of the monitored position is not equal to the target value and the timer value has not exceeded, the power management unit is responsive to the determination The processor is caused to enter the low power state without succumbing to the operating system (OS). The processor of claim 1, further comprising a monitoring engine coupled to the cache memory for determining whether a cache line of the cache memory including the copy of the monitored location is updated. The processor of claim 2, wherein the monitoring engine is configured to deliver the updated copy and the wake-up signal to the core. The processor of claim 3, wherein the core is configured to determine whether the updated copy corresponds to the target value, and if yes, leave the low power state, otherwise determine a new low power state and enter The new low power state. The processor of claim 1, wherein the instruction is a user-level instruction for causing the processor to load the first value, Performing a mask operation between the first value and the data stored in the destination location, and entering the low power state if the result of the mask operation is the first result, otherwise the processor is configured to use the A value is loaded to the destination location. The processor of claim 5, wherein if the result is equal to zero, the processor is configured to set a zero indicator of the flag register. The processor of claim 1, wherein the timer is configured to be a value corresponding to a difference between a timestamp counter value and the timer value. The processor of claim 1, wherein the processor comprises a multi-core processor, the multi-core processor comprising the core and the second core, wherein the instruction is to have a first to be executed on the core The thread and the instruction to update the second thread of the monitored position. The processor of claim 8, wherein the core is configured to leave the low power state in response to the update to the monitored location. The processor of claim 9, wherein the core is configured to perform the use of the information updated by the second thread after the second thread updates the monitored position after that At least one operation of the first thread. A method comprising the steps of: receiving and decoding, in a processor, an instruction from a first application, the instruction specifying an identification of a location to be monitored and a timer value; Responding to the instruction to determine, in the processor based at least in part on the timer value, a type of low power state in which the processor is to enter a plurality of low power states; and if the monitored position value is not equal The target value and the timer value has not passed, and the processor is caused to enter the low power state in response to the determination. The method of claim 11, wherein the instruction further specifies the target value of the monitored position. The method of claim 11, further comprising exiting the low power state in response to exceeding the timer value. The method of claim 11, further comprising leaving the low power state when the value of the monitored position is equal to the target value, comprising waking up by a monitoring engine that receives the cache memory from the processor. The signal, when the stored value of the cache line including the copy of the monitored position has been changed, the monitoring engine transmits the wake-up signal. The method of claim 11, further comprising a power management unit (PMU) using the processor, selecting the low power state from the plurality of low power states according to information in a table having a plurality of entries Type, each entry of the plurality of entries associates a low power state with a timer value, and transmits at least one control signal from the PMU to a core of the processor to cause the core to enter the low power state . The method of claim 11, further comprising receiving a wake-up signal from a second processor coupled to the processor and exiting the low power state in response to the wake-up signal. A system comprising: a multi-core processor comprising a first core and a second core, the first core comprising a decoding logic component and a timer, the decoding logic component for decoding user level instructions to cause a wait state to occur, The user level instructions specify a location to be monitored and a timer value coupled to the decoding logic component to count for the timer value, the multicore processor further including coupling to the And a power management logic component of the second core for selecting, based at least in part on the timer value, one of a plurality of low power states of the plurality of low power states to enter, but not entering the operating system ( OS), and if the value of the monitored location is not equal to the target value, causing the first core to enter the selected low power state in response to the selection; dynamic random access coupled to the multi-core processor Memory (DRAM). The system of claim 17, wherein the first core is configured to perform a mask operation between the first operand and the second operand in response to the instruction of the user hierarchy, and if the mask operation The result is not the target value, then enters the selected low power state. A system as claimed in claim 18, further comprising a monitoring logic component coupled to the first core, the monitoring logic component responsive to the update of the monitored location causing the first core to leave the low Power status. The system of claim 19, wherein the monitoring logic component is used when a cache line associated with the monitored location has been updated When the coherent state of the cache line has been updated, a wake-up signal is transmitted to the first core. An object comprising a machine-accessible storage medium, the machine-accessible storage medium comprising instructions that, when executed, cause the system to: during execution of the first thread, on the multi-core processor a processor in the core receiving the user level waits for an instruction, the processor of the user level waits for an instruction to specify a location to be monitored and a timer value; and determines, in the first core, whether the user level has been processed. Waiting for the condition of the instruction, and if not, entering the low power state selected by the power management logic component of the multi-core processor from the plurality of low power states; updating the value to the second of the multi-core processor During the execution of the second thread on the core; in response to the value update, leaving the low power state of the first core, and determining whether the condition has been met; and if the condition is met, continuing on the first core Execute the first thread. An article of claim 21, further comprising the instructions of causing the system to cause the first core to leave the low power state in response to an update to the monitored location and to update the condition using the value To test. For example, the object of claim 22, further comprising the following instructions: enabling the system to be in the cache line associated with the monitored position When updated, or when the coherent state of the cache line has been updated, the update to the monitored location is determined, and the first core is caused to leave the low power in response to the update to the monitored location status. The article of claim 21, further comprising the following instructions: causing the system to use the power management logic component to select the low power state from a plurality of low power states based on information in a table having a plurality of entries Each entry of the plurality of entries associates a low power state with a timer value and transmits at least one control signal to cause the first core to enter the low power state.