Methods, devices, and instructions for user-level thread suspension

Abstract

A processor of an aspect includes a decode unit to decode a user-level suspend thread instruction to indicate a first alternative state. The processor also includes an execution unit coupled with the decode unit. The execution unit is to execute instructions at a user privilege level. In response to the instruction, the execution unit is to: (a) suspend execution of a user-level thread from which the instruction has been received; (b) transition a logical processor on which the user-level thread would have been running to the indicated first alternative state; and (c) resume execution of the user-level thread by a delay that is to be less than half of a delay at which the thread can be resumed when the logical processor is in a stop processor power state, while the logical processor is in the indicated first alternative state.

Description

Technical Field

[0001] The embodiments described herein generally relate to processors. In particular, the embodiments described herein generally relate to suspending the execution of threads in a processor. Background Technology

[0002] Software threads typically communicate or synchronize by changing the location of shared memory. As an example, a shared memory location can be changed when a lock or semaphore becomes available. As another example, a shared memory location can be changed when work to be performed by a software thread becomes available (e.g., in a work queue).

[0003] One possible method a software thread can use to detect when a shared memory location has been changed is to implement a polling loop, such as an idle loop, a busy loop, a busy-wait loop, or something similar. During the loop, the software thread can repeatedly execute instructions to test whether the shared memory location has changed. Attached Figure Description

[0004] The invention can be best understood by referring to the following description and accompanying drawings, which are used for illustrated embodiments. In the drawings:

[0005] Figure 1 This is a block diagram of an embodiment of a computer system in which embodiments of the present invention can be implemented.

[0006] Figure 2 This is a block diagram of an example embodiment of a Simultaneously Multithreaded (SMT) core suitable for implementation.

[0007] Figure 3 This is a block flowchart illustrating an embodiment of a method for executing a user-level monitor address setting instruction and an embodiment of a method for executing a user-level monitoring access pause thread instruction.

[0008] Figure 4 This is a block diagram of an example embodiment of a logic processor having a C1 processor power state, a C0.1 processor power state, and a C0.2 processor power state.

[0009] Figure 5 This is a block flowchart of a second embodiment of a method for executing a user-level monitoring access suspension thread instruction, the method including using a maximum timeout value imposed by monitoring system software.

[0010] Figure 6 This is a block diagram of an embodiment of a processor operable to execute access-pause thread instructions for user-level monitoring.

[0011] Figure 7This is a block flowchart of an example embodiment of a method for executing a transaction-memory-compatible user-level pause thread instruction within a transaction-memory transaction to pause a first user-level thread without aborting the transaction-memory transaction.

[0012] Figure 8 This is a block flowchart of a second embodiment of a method for executing a transaction memory-compatible user-level pause thread instruction.

[0013] Figure 9A This is a block diagram illustrating an embodiment of an ordered pipeline and an embodiment of a register renaming out-of-order release / execution pipeline.

[0014] Figure 9B This is a block diagram of an embodiment of a processor core that includes a front-end unit coupled to the execution engine unit (and both coupled to the memory unit).

[0015] Figure 10A This is a block diagram of an embodiment of a single processor core along with its connection to the on-die interconnect network and a local subset of its Level 2 (L2) cache.

[0016] Figure 10B yes Figure 10A A block diagram of an embodiment of a partial unfolded view of a processor core.

[0017] Figure 11 This is a block diagram of an embodiment of a processor that may have more than one core, may have an integrated memory controller, and may have integrated graphics.

[0018] Figure 12 This is a block diagram of a first embodiment of a computer architecture.

[0019] Figure 13 This is a block diagram of a second embodiment of a computer architecture.

[0020] Figure 14 This is a block diagram of a third embodiment of a computer architecture.

[0021] Figure 15 This is a block diagram of the fourth embodiment of the computer architecture.

[0022] Figure 16 This is a block diagram illustrating how a software instruction converter is used to convert binary instructions in a source instruction set into binary instructions in a target instruction set, according to an embodiment of the present invention. Detailed Implementation

[0023] This document discloses user-level instructions for pausing threads, processors for executing instructions, methods performed by the processor while processing or executing instructions, and systems that combine one or more processors to process or execute instructions. Numerous specific details (e.g., specific instruction operations, processor configurations, microarchitectural details, logical partitioning / integration decisions, operation sequences, etc.) are set forth in the following description. However, embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, or techniques have not been shown in detail to avoid obscuring the understanding of this description.

[0024] Figure 1 This is a block diagram of an embodiment of a computer system 100 in which embodiments of the present invention can be implemented. The system includes at least one processor 101. The processor 101 is coupled to or otherwise communicates with memory 109 via a coupling mechanism 108. The memory may include one or more memory devices of the same or different types. Various conventional methods of coupling the processor to the memory are suitable. For example, the coupling mechanism may include one or more buses, a hub, a memory controller, a chipset component, or such and various combinations thereof. In various embodiments, the computer system may represent a desktop computer, a laptop computer, a notebook computer, a tablet computer, a netbook, a smartphone, a server, a network device (e.g., a router, a switch, etc.), or other types of systems having one or more processors.

[0025] In some embodiments, processor 101 may be a general-purpose processor (e.g., a general-purpose microprocessor or central processing unit (CPU) of the type used in desktop, laptop, or other computers). Alternatively, the processor may be a special-purpose processor. Examples of suitable special-purpose processors include, but are not limited to: network processors, communication processors, encryption processors, graphics processors, coprocessors, embedded processors, digital signal processors (DSPs), and controllers (e.g., microcontrollers). The processor may have any of a variety of Complex Instruction Set Computing (CISC) architectures, Reduced Instruction Set Computing (RISC) architectures, Very Long Instruction Word (VLIW) architectures, hybrid architectures, other types of architectures, or combinations of different architectures (e.g., different cores may have different architectures).

[0026] Processor 101 includes at least a first logical processor 102-1. Processor 101 may optionally include the first logical processor 102-1 as a single logical processor, or the processor may optionally include multiple such logical processors. The computer system also includes at least a second logical processor 102-2, and may optionally include other logical processors. Dashed lines are used to illustrate that the second logical processor may be part of processor 101 or may be external to processor 101. As an example, the second logical processor may optionally be included on a second processor (e.g., a second die) or in another component (e.g., a direct memory access (DMA) device).

[0027] Examples of suitable types of logical processors include, but are not limited to, single-threaded cores, hardware threads, thread units, thread slots, logical processors with dedicated context or architectural state storage and program counters, logical processors with dedicated context or architectural state storage and program counters on which software can be independently scheduled, and the like. The term "core" is often used to refer to logic located on an integrated circuit that is capable of maintaining an independent architectural state (e.g., execution state), and where the architectural state is associated with dedicated execution and certain other dedicated resources. Conversely, the term "hardware thread" is often used to refer to logic located on an integrated circuit that is capable of maintaining an independent architectural state, and where the architectural state shares access to execution and certain other resources. Depending on which resources are shared and dedicated in a given implementation, the boundary between such uses of the terms "core" and "hardware thread" may tend to be less clear. However, cores, hardware threads, and other logical processors are generally considered by software as separate logical processors or processor elements. Typically, software (e.g., software threads, processors, workloads, or the like) can be scheduled on each logical processor and associated independently with each logical processor.

[0028] The memory may store one or more monitoring system software modules 110, such as one or more operating system modules, one or more virtual machine monitor modules, one or more hypervisors, or the like. The memory may also store one or more user-level application modules 111. Several representative examples of such user-level application modules are word processor application modules, spreadsheet modules, email application modules, internet browser modules, web application modules, video game application modules, and the like. The scope of the invention is not limited to any known type of application module. During operation, the monitoring system software modules may schedule a first software thread 107-1 on a first logical processor and a second software thread 107-2 on a second logical processor.

[0029] During runtime, first and second software threads 107 are operable to access shared memory region 115. As shown, the shared memory region may include first shared memory locations 116-1 to Nth shared memory locations 116-N, where the number N can represent any reasonable number suitable for a particular implementation. Shared memory locations may also optionally be shared by other software threads. In some cases, the first software thread may want to monitor and detect when a second software thread (or another software thread) has written to and / or modified one or more of these memory locations. As an illustrative example, this could be a case combined with synchronization. Representatively, different memory locations may represent locks, semaphores, consumer-producer mailboxes, or the like. When an associated lock or semaphore becomes available, a software thread can modify a given memory location, and the first software thread may want to be able to monitor the memory location so that it can determine when a lock or semaphore becomes available. As another illustrative example, this could be a case combined with work scheduling. Representatively, different memory locations may represent work queues, or flags used to indicate work in an associated work queue. When there is work to be done for the first software thread, the second software thread (or another software thread) may modify the memory location, and the first software thread may want to be able to monitor the memory location so that it can determine when there is available work to be performed.

[0030] One possible way for the first software thread 107-1 to monitor and detect when a given memory location 116 has been modified is by executing an idle loop, a busy loop, a busy-wait loop, or other such polling loops. Such loops typically mean that the thread simply spins in a generally compact loop, repeatedly executing instructions to continuously check or poll whether a modification to the memory location has occurred. However, at least for some implementations, such loops tend to have certain drawbacks. First, such loops tend to consume power without performing any actual work or any meaningful forward computation. Moreover, such loops tend to consume processor resources that might otherwise be potentially used by one or more other threads (e.g., in the case of a Simultaneously Multithreaded (SMT) core). Another possible approach is through sleep. However, sleep tends to be more complex and have longer latency than such polling loops because it involves transitioning to and returning from the operating system. For example, the operating system could maintain a list or wait queue of threads that want to wait. A thread could place itself in the wait queue and request the operating system to wake it up whenever an event occurs (e.g., a write to a memory address). However, such hibernation often tends to have high overhead and latency for user-level applications, partly due to the need to yield or transition to the operating system or other monitoring software and then return (e.g., executing system call instructions to yield to the operating system via a first loop transition and resume from the operating system via a second loop transition). This tends to make user-level code relatively slow to respond. For very short wait times, such polling loops may not be overly problematic and the high latency associated with yielding to the operating system to hibernate can be avoided. Conversely, for very long wait times, the high latency associated with yielding to the operating system to hibernate may also not be overly problematic. However, especially for wait times of medium duration, both such polling loops and yielding to the operating system to hibernate tend to be more problematic. Therefore, alternative methods can offer certain potential advantages, especially for periods of medium duration.

[0031] Refer again Figure 1The first logic processor 102-1 has an instruction set 103. In some embodiments, the instruction set may include an embodiment of an optional user-level set-monitor address instruction 104, an embodiment of an optional user-level monitored access suspend thread instruction 105, and an embodiment of an optional transaction memory-compatible user-level suspend thread instruction 106. In some embodiments, the instruction set may include as few instructions as any one of these instructions. Instructions 104, 105, and 106 are user-level instructions that can be executed with user-level privileges and at higher privilege levels (e.g., through monitoring system software). In some embodiments, the user-level monitored access suspend thread instruction 105 may allow user-level software (e.g., one of the user-level application modules 111) to suspend threads and use a monitor mechanism (which has been established via the user-level set-monitor address instruction 104) to know when one of the shared memory locations 115 has been accessed.

[0032] Advantageously, it may not be necessary to execute idle, busy, or other loops, or even any subsequent instructions. Furthermore, since the user-level monitored access-suspend thread instructions are user-level instructions, which can be executed at user-level privileges (and higher privilege levels), it is neither necessary nor required for the user-level application (e.g., one of user-level application modules 111) to relinquish or otherwise transition to the supervisory system software (e.g., one of the supervisory system software modules 110) to execute the instructions. Instead, instructions can be executed upon entering without leaving user-level privileges, without the need for a loop transition or other transition to a higher privilege level. Moreover, this often allows for better responsiveness to user-level threads, such as handling instructions like "You have email" or "Go get it," by allowing user-level threads to pause and resume more quickly. In one aspect, while embodiments are certainly not limited to this, the ability to execute instructions at the user level can help allow for lower latency, which can be used, for example, by on-die hardware accelerators on the same chip or die as the logic processor, along with data modification. Such on-die hardware accelerators typically have low latency and often require user-level thread-driven or otherwise interfaced relationships, as tripping and returning via privileged system software would have longer latency.

[0033] Figure 2 This is a block diagram of an example embodiment of the Simultaneous Multithreading (SMT) core 220 suitable for this embodiment. The SMT core may include multiple hardware threads, each of which may represent a logical processor or processor element. Each logical processor is operable to execute a different software thread. In this way, multiple different software threads can be executed simultaneously on the SMT core.

[0034] Core 220 is coupled to a bus or other interconnect 221 via a bus and / or memory controller 223. The bus / memory controller can provide instructions 203 for execution on the front end 224 of the core. These instructions may include instructions from the core's instruction set (e.g., instruction set 103), and sometimes include any one or more of the following: user-level set monitor address instruction 105, user-level monitored access pause thread instruction 106, and transaction memory-compatible user-level pause thread instruction 107. The front end may include an instruction fetch unit and a decoding unit. The instruction fetch unit can fetch instructions for multiple threads executed by the core based on multiple corresponding copied instruction pointers (IPs) 226. Instruction pointers can be copied per thread to support multiple threads. The decoding unit can decode the received instructions for each thread.

[0035] Decoded instructions or control signals can be provided from the front end to the first set of thread-partitionable resources 225 for further processing. As an example, the first set of thread-partitionable resources may include a queue of decoded instructions. Thread-partitionable resources may include logically separate partitions, each of which can be dedicated to a specific thread when multiple threads are active within the kernel. In some embodiments, each individual partition may contain only instructions from the corresponding thread to which that partition is dedicated. As will be further explained below, in some alternative states, when the kernel is in single-threaded mode, the partitions of the first set of thread-partitionable resources may optionally be annealed or otherwise combined to form a single large partition dedicated to a single thread (or any remaining execution threads). The partitioning and combination of partitionable resources can be performed based on which threads are active or suspended in the kernel.

[0036] The core also includes multiple sets of replicated state storage devices 227. For example, a set of replicated state storage devices may exist for each thread active on the core and / or for each hardware thread of the core. The replicated state storage devices may include, for example, architecture registers and other storage devices for storing state or context. Each set of replicated state storage devices is operable to store enough state to maintain the context or architecture state of the corresponding hardware thread or logic processor. By replicating the state storage devices, multiple threads can execute substantially without contention for the state storage devices. Additionally, the associated register allocation logic may be replicated for each thread. The replicated state-related logic may operate in conjunction with appropriate resource partitioning to prepare incoming instructions for execution.

[0037] The first set of thread-partitionable resources 225 can provide decoded instructions to shared resource 228. For example, the first set of partitionable resources can attempt to provide continuous process on each active thread by alternating instructions from multiple threads (e.g., in a fair or normally alternating manner) between threads. For example, thread selection multiplexing logic can alternate between partitioned resources to provide reasonable access to each active thread. Shared resources can operate on instructions from multiple threads. As an example, shared resources may include a scheduler, execution units, and register pools in the register read and write sections of a pipeline.

[0038] The second set of thread-partitionable resources 229 can be coupled to the output of shared resource 228. The second set of thread-partitionable resources can include retire or commit resources, such as, for example, a reordering buffer or the like. The second set of thread-partitionable resources can commit instructions from each thread and update the appropriate architectural state of the thread.

[0039] It should be understood that this is merely an illustrative example of a suitable SMT core. In other embodiments, shared and thread-partitionable resources may be arranged differently. For example, there may be no partitionable resources at either end of a shared resource. Additionally, in other embodiments, partitionable resources may not be strictly partitioned, but rather some instructions may be allowed to cross partitions and / or partitions may be allowed to vary in size depending on factors such as the specific thread executing with that partition and the total number of threads executing. Furthermore, different mixtures of resources can be specified as shared, replicated, and partitioned resources.

[0040] One potential advantage of SMT cores is their ability to improve processor utilization by allowing multiple software threads to execute on a single core. This is especially true when the core has a highly parallel architecture, making it sometimes difficult to extract sufficient parallelism from a single thread to utilize all execution units. However, with SMT, multiple threads can be executed simultaneously across different execution resources to attempt better utilization of those resources. Furthermore, such SMT cores may be helpful for applications encountering high latency or frequently waiting for events. While one thread is waiting for a high-latency task to complete or for a specific event, another thread can handle the workload.

[0041] Figure 3 This is a block flowchart illustrating an embodiment of a method 334 for executing user-level monitor address setting instructions and an embodiment of a method 340 for executing user-level monitoring access pausing thread instructions. In some embodiments, these two instructions can be used together to pause a thread while waiting for a write / store access to a monitored memory location. Alternatively, a single instruction can combine the operations of two instructions. In various embodiments, the methods can be executed by a processor, instruction processing device, digital logic device, or integrated circuit.

[0042] First, refer to method 334 for executing user-level set-up monitor address instructions. This method includes receiving user-level set-up monitor address instructions from a first user-level thread in block 335. In various respects, the instructions may be received at the processor or a portion thereof (e.g., instruction fetch unit, decode unit, bus interface unit, etc.). In various respects, the instructions may be received from external and / or off-die sources (e.g., from memory, interconnect, etc.) or from on-processor and / or on-die sources (e.g., from instruction cache, instruction queue, etc.).

[0043] In some embodiments, user-level monitor address setting instructions may explicitly specify (e.g., via one or more fields or a set of bits) or otherwise indicate (e.g., implicitly via opcodes) a memory address to be monitored (e.g., for write / store accesses to a memory address). Instructions may “indicate” a monitor address because they can carry enough information to allow the processor to determine the address to be monitored (possibly using information in one or more registers, such as segment registers, and / or other information). In one aspect, the instructions may indicate a linear address having a corresponding physical address to be monitored for an access (e.g., based on address translation). As other examples, the monitored address may be given in virtual address format, or may be indicated as a relative address, or may be specified in other known or convenient address specification methods. The monitor address may indicate various units of memory for monitoring. For example, in some embodiments, the memory address may indicate a cache line. Alternatively, the memory address may indicate a portion of a cache line, a specific / selected size portion or unit of memory, which may carry different relationships to cache line sizes for different processors, or a single address. Therefore, the monitor address can indicate a cell that includes data (and more data) specified by the operand, or it can specifically indicate the address of the desired cell for the data. In some embodiments, the indicated memory address or range can be a write-back cache type.

[0044] In some cases, instructions may optionally have a source operand specification field to specify a register (e.g., a general-purpose register) or another storage location to store information indicating the memory address to be monitored. In other cases, the register (e.g., a general-purpose register) or another storage location to store information indicating the memory address to be monitored may optionally be implicit in the instruction (e.g., implicit in the instruction's opcode). For example, the processor may implicitly understand, based on the identification of the opcode, that a register or another storage location is used to store information indicating the memory address, even if the instruction does not explicitly specify or identify that register or another storage location. Software may store information indicating the memory address to be monitored in a register or another storage location before executing user-level instructions to set the monitor address.

[0045] In block 336, the processor's address monitor logic may be set up or configured to monitor access to a memory address indicated by a user-level set monitor address instruction in response to and / or as a result of a user-level set monitor address instruction. In some embodiments, this may include notifying the address monitor logic of the memory address to be monitored. For example, the memory address to be monitored may be stored within the address monitor logic and / or in a non-architectural register or another storage location accessible to it. In some embodiments, this may also optionally include increasing the observability of writes / stores to the monitored address (e.g., causing a cache proxy to perform a write operation that will affect information stored in the address monitor logic that is visible to the address monitor logic). In some embodiments, setting up or configuring the address monitor logic to monitor access to the memory address may also include turning on, activating, or enabling the address monitor logic to monitor access to the memory address (e.g., write access).

[0046] In some embodiments, the address monitor logic for monitoring may primarily comprise or only comprise on-die logic of the processor. For example, the address monitor logic may be entirely or at least primarily on-die hardware (e.g., integrated circuits, transistors, or other circuit elements), on-die firmware (e.g., ROM, EPROM, flash memory, or other persistent or non-volatile memory and microcode, microinstructions, or other low-level instructions stored therein), or a combination thereof. In other embodiments, the address monitor logic may include on-die hardware and / or on-die firmware that optionally / potentially have some software. The address monitor logic may also be referred to herein simply as a monitor, address monitor, or monitor unit.

[0047] In block 337, the established or configured address monitor logic can monitor accesses to indicated memory addresses. Once activated or enabled, the address monitor logic can begin operating sequentially in parallel with other operations in the processor to monitor such accesses. The address monitor logic may include comparison logic for comparing the memory address to be monitored with bus cycle information (e.g., received from the bus and / or memory controller). Memory access information can be obtained from the processor's internal and / or external buses. In some embodiments, physical addresses can be compared. For example, a linear or other logical address indicated by an instruction can be translated by address translation logic (e.g., a translation back buffer (TLB), a page miss handler, or the like) to obtain a physical address. In such embodiments, the address monitor logic can monitor any bus cycles indicating an actual or potential write to that physical address. Such cycles can be in the form of explicit write cycles and / or can be reads of ownership or invalidation cycles performed by another agent attempting to acquire exclusive ownership of a cacheable line, allowing it to be written to that line without external bus transactions. In the case of reading the monitor address, consistency-related logic can be activated, and it can assert signals (e.g., the HIT# signal) to help prevent another agent from gaining ownership, which would allow future writes without consistency broadcasting. If an access to the monitored memory address (e.g., the associated cache line or address range) is detected, the method can proceed to box 338. Otherwise, the address monitor logic can continue monitoring for attempted accesses until it is deactivated.

[0048] At box 338, the address monitor logic and / or processor may indicate that an attempt to write / store access to the monitored address has been detected. This indication may be given in different ways in different embodiments. In various embodiments, this indication may be given by setting or otherwise modifying bits, storing or modifying values ​​in registers or memory locations, transmitting or asserting signals (e.g., write detection signals), incrementing a counter, or the like. In some embodiments, this indication may indicate that another logic processor has modified a shared memory location (e.g., indicating that a lock or semaphore is available, indicating the availability of work to be performed in a queue, etc.). As will be further explained below, in some embodiments, this indication may be used to resume the execution of a suspended thread.

[0049] Refer again Figure 3 Next, a method 340 for executing user-level monitoring access pause thread instructions will be described. In block 341, user-level monitoring access pause thread instructions may be received. In some embodiments, user-level monitoring access pause thread instructions may be received from the same first user-level thread (e.g., from which user-level set-up monitor address instructions are received at block 335).

[0050] In some embodiments, the user-level monitored access pause thread instruction may optionally specify or otherwise indicate a timeout value (e.g., as a source operand). In the absence of prior detection of events for the monitored address and / or other resume threads, the timeout value may represent the limit or maximum value of the first user-level thread to be paused, as indicated by the user-level monitored access pause thread instruction. Timeout values ​​can be expressed in various ways, such as, for example, a value to which a counter will increment, a value to which a counter will decrement, a value to which a counter will decrement to zero, a value to which a timer will count, a value to which a timer will count, a value to which a timer will count, a value to which a timer will count, a duration of a global clock or other clock time, a final global clock or other clock time, multiple processor clock cycles, or the like. For clarity, timeout values ​​or times can represent various increments of time, durations of time, or actual termination times (e.g., to illustrate the difference, resumption at time 8:01:32:32, or resumption after 1 / 10000 of a second from now).

[0051] The timeout value can represent a user-level value (e.g., provided by a user-level application and / or user-level privileges). The programmer and / or user-level application can choose the timeout value based on how long the pause should be. In some embodiments, the instruction may have bits or fields for specifying or otherwise indicating the timeout value. As an example, the instruction may have a length of 4 bits, 6 bits, 8 bits, or other bits immediately to specify the timeout value. In other embodiments, the instruction may have bits or fields for indicating a register or other storage location where information for specifying or otherwise indicating the timeout value will be stored. Alternatively, such a register or other storage location may be optionally implicit in the instruction (e.g., implicit in its opcode). Alternatively, a fixed user-level timeout value may be optionally used in the instruction (e.g., fixed to the opcode and / or implicit in the opcode).

[0052] In some embodiments, the user-level monitored access-pause thread instruction may specify or otherwise indicate a given one of a plurality of possible alternative states that the associated logic processor will transition to when the first user-level thread is paused. In some embodiments, the opcode of the user-level monitored access-pause thread instruction may optionally allow any one of such plurality of possible alternative states, and another non-opcode portion of the instruction may indicate one of the plurality of possible alternative states. Alternatively, in other embodiments, different opcodes may optionally be used for different states.

[0053] In different embodiments, instructions may specify or otherwise indicate alternative states in different ways. In some embodiments, an instruction may have one or more bits or fields that may have different values ​​for specifying, selecting, or otherwise indicating a given one of a plurality of possible alternative states. As an illustrative example, a single bit of an instruction may have a first value for indicating a first alternative state (e.g., set to binary one) or a second different value for indicating a second different alternative state (e.g., cleared to binary zero). Alternatively, two or more bits may be used to select among three or more different possible alternative states. In other embodiments, an instruction may have bits or fields for indicating a register or other storage location that will store information for specifying, selecting, or otherwise indicating a given one of two or more possible alternative states. Alternatively, such a register or other storage location may be optionally implicit in the instruction (e.g., implicit in its opcode). In other embodiments still present, the magnitude of the timeout value indicated by the instruction itself can be used to indicate a given one of a plurality of different possible alternative states. As an illustrative example, a timeout value less than a threshold or predetermined value may indicate a first alternative state, or a timeout value greater than a threshold or predetermined value may indicate a second alternative state. Three or more distinct states can be similarly achieved by using two or more different thresholds or predetermined values.

[0054] Allowing instructions to indicate a given one of several possible alternative states can help allow programmers and / or user-level software to indicate preferences for how long the delay for resuming execution should be and / or how aggressive a power-saving state should be used when a thread is paused, but this is not required. In some embodiments, the several possible alternative states may include relatively long resumption execution delay states for the logical processor (e.g., a sleep state) and relatively short resumption execution delay states for the logical processor (e.g., a lighter sleep state). As used herein, “longer” and “shorter” are used as relative terms (i.e., relative to each other), not absolute terms. Moreover, “lighter” in a “lighter sleep” state means that it is lighter than a sleep. In some embodiments, a relatively long resumption execution delay state (e.g., a sleep state) may also have relatively more aggressive power-saving measures, and a relatively short resumption execution delay state (e.g., a lighter sleep state) may have relatively less aggressive power-saving measures. Again, “more” and “less” in this context are used as relative terms (i.e., relative to each other), not absolute terms. If desired, the multiple states may optionally include three or more distinct states, each with a different level of relative recovery execution latency and / or power saving positivity.

[0055] In some embodiments, at least one (or optionally all) of one or more possible / permitted alternative states of a user-level monitored access thread pause instruction may have a recovery execution latency less than or at least no longer than the recovery execution latency of a C1 or stopped processor power state as defined by the current version of the Advanced Configuration & Power Interface (ACPI). The recovery execution latency of a C1 or stopped processor power state from the ACPI is sometimes described as “virtually instantaneous,” although in practice it typically takes about a thousand clock cycles. As used herein, “C1 state” and “stopped processor power state” refer to those defined by the ACPI. Representatively, since the instructions are user-level instructions, it may be useful in some cases if user-level code can be allowed (or in some embodiments only allowed) to have a recovery execution latency shorter than or at least no longer than the recovery execution latency of a C1 or stopped processor power state. As a possible example, the monitoring system software may not want user-level code to be able to autonomously enter alternative states as deep as the C1 or stopped processor power state, allowing the monitoring system software more control over platform power management. As a possible reason, if user-level code is allowed to autonomously enter or stop the processor power state or deeper sleep state, the performance monitoring counters and / or other methods used by the monitoring system software to measure the amount of time spent in different C states may be potentially inaccurate.

[0056] In some embodiments, the instructions may optionally allow a first alternative state (e.g., a lighter sleep state), which may be represented by the ACPI C state notation as state C0.1. In some embodiments, state C0.1 may have a recovery execution delay no longer than approximately half (e.g., no more than approximately 500 clock cycles) of the recovery execution delay of ACPI C1 or the stopped processor power state. In various embodiments, the recovery execution delay of state C0.1 may be no more than approximately one-third (e.g., no more than approximately 333 clock cycles) of the recovery execution delay of C1 or the stopped processor power state, no more than approximately one-quarter (e.g., no more than approximately 250 clock cycles) of the recovery execution delay of C1 or the stopped processor power state, no more than approximately one-fifth (e.g., no more than approximately 200 clock cycles) of the recovery execution delay of C1 or the stopped processor power state, no more than approximately one-eighth (e.g., no more than approximately 125 clock cycles) of the recovery execution delay of C1 or the stopped processor power state, or no more than approximately one-tenth (e.g., no more than approximately 100 clock cycles) of the recovery execution delay of C1 or the stopped processor power state. In some embodiments, the instructions may also optionally allow a second alternative state (e.g., a sleep state), which may be represented by the ACPI C state notation as state C0.2. In some embodiments, state C0.2 may have a recovery execution delay that is slightly shorter than or at least no longer than the recovery execution delay of state C1 or the stopped processor power state (e.g., no greater than the equivalent of approximately one thousand clock cycles).

[0057] In some embodiments, by allowing user-level instructions to have only a recovery execution latency not significantly more than that of the aforementioned C0.2 state, it can preserve the limitation that only the supervisory system software can enter a sleep state as deep as the C1 or stopped processor power state. In some embodiments, the supervisory system software may use performance monitoring counters and / or other methods to measure the amount of time spent in different C states, potentially treating the time spent in C0.1 or C0.2 as the time spent in the C0 or active state of ACPI. In other words, even though the C0.2 state may potentially have similar recovery latency and / or similar power savings as the C1 or stopped processor power state, the supervisory system software may treat it as an active state, which would not be the case for the C1 or stopped state.

[0058] Refer again Figure 3In some embodiments, at block 342, the processor may optionally perform an initial determination of whether the address watcher logic is activated. This may optionally be done before pausing execution of the first user-level thread. As an example, when the address watcher logic is set up in response to different instructions, this can help ensure that the address watcher logic is actually set up and activated, which can help avoid a potential situation where the first thread might be paused for a longer period than expected because the address watcher logic is not actually activated. However, this is optional and not required. If it is determined that the address watcher logic is activated (i.e., "yes" is determined), the method may proceed to block 343. Otherwise, if the address watcher logic is not activated (i.e., "no" is determined), the method may proceed to block 346.

[0059] In box 343, in response to a user-level monitored access pause thread instruction (e.g., in response to an instruction being decoded), execution of a first user-level thread can be paused and the logical processor on which the first user-level thread was running can be transitioned to an indicated alternative state. As used herein, pausing thread execution includes additional instructions to temporarily terminate thread execution until the thread is resumed. In some embodiments, the manner in which the logical processor is transitioned to the indicated alternative state may be based on and / or depend on the alternative state indicated by the user-level monitored access pause thread instruction. For example, in some embodiments, the set of actions taken to transition the logical processor (e.g., in conjunction with freeing up processor resources for another thread) when indicating a relatively short resumption execution delay state (e.g., a light sleep state) may differ in at least some ways from the set of actions taken when indicating a relatively long resumption execution delay state (e.g., a sleep state).

[0060] For example, in some embodiments, one or more sets of partitionable resources previously initially allocated to a first user-level thread (e.g., running on a first SMT hardware thread) may not be fused or annealed for use by a second software thread (running on a second SMT hardware thread on the same core) when indicating a relatively short recovery execution latency state (e.g., a light sleep state), but these one or more sets of partitionable resources may be fused or annealed for use by the second software thread when indicating a relatively long recovery execution latency state (e.g., a sleep state). For example, when entering a relatively short recovery execution latency state, the first user-level thread may be paused, but a relatively large portion of its partitionable resources may be retained. Throughput can still be enhanced because shared resources can be exclusively used by other threads while the first user-level thread is paused. Conversely, when entering a relatively long recovery execution latency state, the first user-level thread may be paused, and a relatively large portion of its partitionable resources previously dedicated to the first user-level thread may also be relinquished during its pause (e.g., for...). Figure 2 (Any partitionable resources discussed). This allows other threads to use these resources, which can help increase the throughput of those other threads. However, giving up these resources may come at the cost of some increased recovery execution latency associated with merging / combining these partitionable resources. Therefore, such partitionable resources can be merged / combined for relatively long expected recovery execution latencies, but not so much for relatively short expected recovery execution latencies. This is just an illustrative example. In other embodiments, the two states can be viewed differently at the microarchitecture level. For example, in another embodiment, in a shorter recovery execution latency state (e.g., a lighter sleep state or C0.1 state), the clock may not be terminated or gated to at least some hardware resources, while in a longer recovery execution latency state (e.g., a sleep state or C0.2 state), the clock may be stopped or gated to these hardware resources.

[0061] The section above, concerning box 343, discusses how a processor, in response to an instruction, can suspend the execution of a first user-level thread and transition the logical processor to an indicated alternative state. It should be understood that this discussion, in some embodiments, covers the possibility that the processor may optionally first determine or ensure that one or more conditions are met. As an example, these conditions may relate to whether the processor will be able to resume execution, and / or detect events that would otherwise require the thread to resume execution, and / or other conditions that would not be expected to allow the logical processor to enter the indicated alternative state. Specific conditions for a particular implementation may be partly due to model-specific and / or microarchitectural design. As an example, these conditions may determine whether the processor currently lacks the resources required to reliably detect whether access to an address that will need to be monitored is taking place. In some embodiments, if such conditions are not met, the processor may optionally decide to suspend the execution of the user-level thread and transition the logical processor to an alternative state different from the indicated alternative state, or may decide not to suspend the execution of the user-level thread at all. Therefore, suspending the execution of the user-level thread in response to an instruction and transitioning the logical processor to the indicated alternative state encompasses adjusting it according to one or more conditions that are being met.

[0062] In blocks 344 and 345, a determination can be made as to whether to resume execution of the first user-level thread. Specifically, in block 344, a determination can be made as to whether an indication has been detected of access to a monitored memory address (e.g., the memory address indicated by a user-level set-monitor address instruction). For example, in some embodiments, this determination may be associated with determining at block 338 whether the address monitor logic has indicated that an access to the monitored address has been detected. In various embodiments, such a determination can be made by determining the value of a bit, a value in a register, or a value in a memory location that indicates whether an access to the monitored address has been detected. In other embodiments, such a determination can be made by determining whether a signal indicating that an access to the monitored address has been detected has been transmitted or asserted. In some embodiments, an indication that an access to the monitored memory location has been detected may indicate that another logical processor has modified the shared memory location at the memory address (e.g., indicating that a lock or semaphore is available, indicating the availability of work to be performed in a queue, or the like). Note that no additional instructions need to be executed to resume the first user-level thread. Conversely, the first user-level thread can remain suspended, and the processor (e.g., enabled address monitor logic and thread suspension and resumption logic) can autonomously monitor and detect memory accesses to the monitored memory locations and prompt the first user-level thread to resume without executing any additional instructions. If an indication of access to the monitored memory address has been detected (i.e., "yes" is the determination at box 344), the method can proceed to box 346. Otherwise, if no indication of access to the monitored memory address has been detected (i.e., "no" is the determination at box 344), the method can proceed to box 345.

[0063] At box 345, a determination can optionally be made as to whether the user-level timeout value indicated by the user-level monitored access pause thread instruction has expired. As previously mentioned, the use of this timeout value is optional and not required. The timeout value may represent the maximum value at which the first user-level thread remains in the suspended execution state, as indicated by the user-level monitored access pause thread instruction. This determination can be made in different ways in different embodiments. For example, in various embodiments, this may include determining whether a counter that began approximately at the time the first user-level thread was suspended has incremented to the timeout value, or decremented to zero or a stop value from the start of the timeout value; determining whether the time period that has elapsed approximately since the first user-level thread was suspended is equal to or greater than the timeout value; determining whether approximately the number of clock cycles of the timeout value has occurred since the first user-level thread was suspended; or something similar. If the timeout value has expired (i.e., "yes" is the determination at box 345), the method may proceed to box 346. Otherwise, if the timeout value has not expired (i.e., "No" is the determination at box 345), the method can revisit box 344.

[0064] At box 346, execution can resume from an indicated alternative state to which the logic processor previously transitioned (e.g., that of the first user-level thread). For example, if a "yes" determination is made at one of boxes 344-345, execution of the first user-level thread can continue on the next instruction of the first user-level thread following a user-level monitored access-suspend thread instruction, or execution can be transferred to the processor if any interrupt or other event (not shown) that should be handled by privileged software is detected.

[0065] In some embodiments, the latency by which execution can be resumed may depend on a particular indicated alternative state. For example, the manner in which execution can be resumed from an indicated first alternative state may be based on and / or depend on the particular indicated alternative state and what actions need to be performed to transition the logical processor back to an executable state. Often, this resumption may be essentially a reversal of the actions taken at block 343 to transition the logical processor to the indicated alternative state. For example, in some embodiments, when resuming execution from a relatively short resumption latency state (e.g., a lighter sleep state), it may not be necessary to combine / merge one or more sets of partitionable resources (e.g., which may remain partitioned and allocated to a first user-level thread), whereas when resuming execution from a relatively long resumption latency state (e.g., a sleep state), previously merged / annealed resources may be repartitioned and reallocated.

[0066] In some embodiments, the indicated alternative state may have a lower recovery execution latency than the ACPI C1 or stopped processor power state. In such embodiments, execution can be resumed from the logical processor in the indicated alternative state by a latency less than half, less than one-third, less than one-quarter, less than one-fifth, less than one-eighth, less than one-tenth, or even less than the latency at which the thread can be resumed when the logical processor is in the ACPI C1 or stopped processor power state. In some embodiments, alternatively, one or more other possible / permitted alternative states may also be optionally supported by a recovery execution latency that is also less than and / or at least not greater than the recovery execution latency of the ACPI C1 or stopped processor power state. Providing two or more alternative states can help provide programmers or user-level software with trade-off options to choose between a relatively long recovery execution latency state (which tends to improve the performance of another SMT thread by allowing more resources to be sacrificed) and a relatively short recovery execution latency state (which may generally not allow performance improvement for another SMT thread, but generally allows the first user-level thread to resume faster).

[0067] Methods 334 and 340 have been shown and described in a relatively basic form, but operations may optionally be added to and / or removed from the methods. For example, method 340 may be optionally modified, if desired, to remove aspects of the processor or other device that, in conjunction with pre-formed user-level monitored access pause thread instructions, allow multiple alternative possible states, and optionally remove aspects of the user-level monitored access pause thread instructions that indicate one of these multiple possible alternative states. Of course, a single fixed alternative state (e.g., a lighter sleep state) may optionally be used. As another example, in other embodiments, method 340 may be optionally modified to include applying a maximum time or timeout value for the monitoring system software and / or privilege level (e.g., as will be combined below). Figure 5(Further description follows). As another example still available, although not shown for simplicity, in some embodiments, method 340 may optionally allow one or more other types of events to prompt the first user-level thread to resume, although this is not required. For example, one or more additional determining blocks similar to blocks 344 and 345 may be optionally added. In various embodiments, these determining blocks may determine whether an unmasked interrupt (NMI), system management interrupt (SMI), debug exception, machine check exception, startup signal, reset signal, certain types of external interrupts (if they will be delivered to software), address translation change events, or the like have been detected, and if so, prompt the resumption of execution of the first user-level thread. Furthermore, while the flowchart of the method illustrates a particular sequence of operations, this sequence is merely an example and not required. Alternative embodiments may perform some operations in a different order, combine some operations, overlap some operations, etc. For example, the determinations at blocks 344 and 345 may optionally be performed in a different order and / or simultaneously, etc.

[0068] In the above description, methods responding to two different instructions (e.g., two different opcodes) have been shown and described. Using two different instructions to set up the address monitor logic and suspend the thread may tend to provide programmers with increased flexibility and / or tend to allow for more efficient programming. Alternatively, in other embodiments, the aforementioned operations may be performed in response to a single instruction (e.g., a single opcode) and / or as a result of a single instruction.

[0069] Figure 4 This is a block diagram of an example embodiment of a logic processor 402 having a set of suitable alternative power states. The logic processor has or supports a C1 or stopped processor power state 447. The logic processor may optionally have or support an optional C0.2 processor power state 448. The logic processor has or supports a C0.1 processor power state 449. As generally shown in reference 450, the recovery execution latency of the C0.1 power state may be less than the recovery execution latency of the C0.2 processor power state, and the recovery execution latency of the C0.2 power state may be less than, similar to, or approximately equal to but substantially no greater than the recovery execution latency of the C1 or stopped processor power state.

[0070] Figure 5 This is a block flowchart of a second embodiment of a method 540 for executing user-level monitoring access suspension thread instructions, the method including applying a maximum timeout value using monitoring system software. In various embodiments, the method may be executed by a processor, instruction processing device, digital logic device, or integrated circuit. Method 540 and... Figure 3 Method 340 has some similarities. To avoid making the description difficult to understand, the main description will be... Figure 5 The methods differ and / or additional aspects, without repeating information about Figure 3 All alternative similar or common aspects and details of the method. However, to understand, unless stated or otherwise clearly obvious, Figure 3 The aspects and details of the previously described method, as well as the variations mentioned therein, may also be optionally applied. Figure 5 The method. Mainly, Figure 5 The difference lies in that it further adds a maximum timeout value imposed using the monitoring system software (e.g., as discussed in conjunction with box 560), and allows multiple alternative states to be optional. This can be combined with execution... Figure 3 The user-level setting monitor address instruction is executed in the previously described method 334. Figure 5 The method is described, but the scope of the present invention is not limited to this aspect.

[0071] refer to Figure 5 In box 541, a user-level monitoring access pause thread instruction can be received from the first user-level thread. In some embodiments, the instruction may optionally specify or otherwise indicate a user-level timeout value (e.g., optionally as previously combined). Figure 3 (As described). In some embodiments, the instructions may specify or otherwise indicate a given one of a plurality of possible alternative states that the logical processor will transition to when the first user-level thread is suspended (e.g., optionally as previously described). Figure 3 (As described), although this is not required. If used, such multiple alternative states can optionally be combined with previously described states. Figure 3 Any of the described alternative states are similar or identical. However, it is optional (not required) that the processor or other device executing the method is operable to combine execution instructions to support such multiple alternative states. Furthermore, it is optional (not required) that instructions (e.g., their opcodes) are operable to support such multiple alternative states. In some embodiments, alternatively, the processor and / or instructions may optionally indicate and support only a single alternative state when the first thread is suspended (e.g., a single alternative state may optionally be implicit in the instructions (e.g., their opcodes)). For example, a lighter sleep and / or C0.1 state may optionally be implicit.

[0072] Refer again Figure 5 In some embodiments, at block 542, the processor may optionally perform an initial determination of whether to activate the address monitor logic. For example, this may optionally be combined as previously described. Figure 3The method shall proceed as described in box 342. If the address monitor logic is activated (i.e., "yes" is determined), the method may proceed to box 543. Otherwise, if the address monitor logic is not activated (i.e., "no" is determined), the method may proceed to box 546.

[0073] In box 543, execution of the first user-level thread can be paused, and the logical processor on which the first user-level thread was running can be transitioned to the indicated alternative state. As previously described, depending on the indicated alternative state, different delays may be required to resume execution (e.g., due to changes made during the transition to the indicated alternative state). For example, this can optionally be combined as previously described. Figure 3 It is accomplished as described in box 343.

[0074] In boxes 544, 545, and 560, a determination can be made as to whether to resume execution (e.g., of the first user-level thread). Specifically, in box 544, a determination can be made as to whether an indication of access to a monitored memory address has been detected. For example, this can optionally be combined as previously described. Figure 3 The process is performed as described in box 344. If an indication of access to the monitored memory address has been detected (i.e., "yes" is confirmed), the method may proceed to box 546. Otherwise, if no indication of access to the monitored memory address has been detected (i.e., "no" is confirmed), the method may proceed to box 545.

[0075] In box 545, a determination can optionally be made as to whether the user-level timeout value indicated by the instruction has expired. For example, this can optionally be combined as previously described. Figure 3 The process is performed as described in box 345. If the timeout value has expired (i.e., "yes" is confirmed), the method proceeds to box 546. Otherwise, if the timeout value has not expired (i.e., "no" is confirmed), the method proceeds to box 560.

[0076] At box 560, a determination can be made as to whether the maximum time or timeout value imposed by the supervisory system software and / or the privilege level has expired. For simplicity, the maximum time or timeout value imposed by the supervisory system software and / or the privilege level may also be referred to herein as the timeout value imposed by the supervisory system software. The timeout value imposed by the supervisory system software may represent a limit or maximum time or duration-related value that allows the first user-level thread to remain suspended in the absence of prior detection of access to the monitored address (e.g., in box 544) and / or the optional user-level timeout value has not expired (e.g., as determined in box 545). As an example, imposing a timeout value imposed by the supervisory system software can help prevent the first user-level thread from using processor resources for an excessively long time when the supervisory system software may want to use processor resources for another purpose. In contrast to the user-level timeout value discussed in conjunction with box 545, the timeout value imposed by the supervisory system software may be provided by the supervisory system software (e.g., an operating system module, a virtual machine monitor module, or the like) and / or from the privilege level of operation (e.g., at least higher than user-level privilege). Therefore, in some embodiments, the maximum timeout value may optionally be provided from user-level privileges or perspectives, or from both privilege levels or perspectives.

[0077] The timeout value imposed by the monitoring system software can be expressed in various different ways, such as, for example, the value to which a counter will increment, the value to which a counter will decrement, the value from which a counter will decrement to zero, the value to which a timer will count, the value to which a timer will count, the value from which a timer will count to zero, the duration of a global clock or other clock, multiple processor clock cycles, or the like.

[0078] In some embodiments, the timeout value imposed by the supervisory system software may be stored or provided by the supervisory system software and / or from the privilege level of execution in a register or another storage location. For example, in some embodiments, the processor may have a model-specific register (MSR) or another control register that can be used to store the timeout value imposed by the supervisory system software. The MSR or other control register may optionally be implicit in the instruction (e.g., implicit in its opcode) without needing to be explicitly specified. Alternatively, the timeout value imposed by the supervisory system software may optionally be configured in a different manner.

[0079] If the timeout value imposed by the monitoring system software has not expired (i.e., "No" is the determination at box 560), the method may revisit box 544, where additional determinations may be optionally made in the repeating loop until an exit condition from the loop is detected. Alternatively, if the timeout value imposed by the monitoring system software has expired (i.e., "Yes" is the determination at box 560), the method may proceed to box 561.

[0080] In box 561, the following indication may be stored or otherwise provided: the suspension of a first user-level thread is being terminated due to the expiration of a timeout value imposed by the monitoring system software. This may represent an indication or communication to the first user-level thread and / or its associated user-level application that the first user-level thread has been resumed because the timeout value imposed by the monitoring system software expired and / or the monitoring system software restricted it, rather than for some other reason (e.g., a monitored memory access was detected, an optional user-level timeout value expired, an interrupt or other event was detected, etc.).

[0081] In different embodiments, the indication at block 561 can be provided in different ways. For example, in various embodiments, the indication can be provided by setting or otherwise modifying one or more bits, setting or otherwise modifying one or more flags (e.g., one or more bits in an architecture flag or status register), storing a value in a register or memory location, or transmitting or asserting one or more signals. In a particular example embodiment, this indication can be provided by modifying a flag (e.g., setting a bit corresponding to a flag in a register used to implement the architecture flag), such as, for example, a zero flag, a carry flag, a new dedicated flag (if desired), or some other flag.

[0082] The first user-level thread and / or its associated user-level application may be able to receive or observe an indication that the first user-level thread's suspension has been terminated due to a timeout value imposed by the supervisory system software. In some embodiments, this indication may optionally serve as communication or notification between the supervisory system software and the user-level application that the supervisory system software has something it wishes to do better with respect to the processor resources currently allocated to the first user-level thread and / or that the supervisory system software wishes the first user-level thread to relinquish control to it. Optionally, there may be an understanding, agreement, or contract in which, in the presence of such an indication, the first user-level thread should transfer control to the supervisory system software, such as, for example, by relinquishing control to an operating system module and placing itself into a wait queue associated with a sleep state. However, implementing such an understanding or agreement is optional and not required.

[0083] In box 546, execution can resume from an indicated alternative state (e.g., that of a first user-level thread) to which the logical processor has transitioned. For example, this can optionally be combined as previously described. Figure 3This is accomplished as described in box 346. In some embodiments, execution can be resumed from the logical processor in an indicated alternative state by a delay that is less than half, less than one-third, less than one-fifth, less than one-eighth, or even less of the delay at which execution can be resumed when the logical processor is in ACPI C1 or stopped processor power state. In some embodiments, alternatively, one or more other alternative states can be optionally supported by a resumption execution delay that is less than or at least not greater than the resumption execution delay of ACPI C1 or stopped processor power state.

[0084] Method 540 has been shown and described in a relatively basic form, but operations may optionally be added to and / or removed from the method. For example, although not shown for simplicity, in some embodiments, method 340 may optionally allow one or more other types of events to prompt the first user-level thread to resume, although this is not required. For example, one or more additional determining boxes similar to boxes 344 and 345 may optionally be added. In various embodiments, these determining boxes may determine whether an unmasked interrupt (NMI), system management interrupt (SMI), debug exception, machine check exception, start signal, reset signal, certain types of external interrupts (if they are to be delivered to software), address translation events, or the like have been detected, and if so, prompt the resumption of execution of the first user-level thread. As another example, in some embodiments, if desired, the privilege level of the monitoring system software module and / or execution may also optionally have other controls, such as, for example, the ability to adjust or control or determine whether to allow entry into an alternative state when the first user-level thread is suspended. For example, in some embodiments, the privilege level of the monitoring system software and / or execution may optionally be configured to allow entry into a relatively short recovery execution delay state, but prevent entry into a relatively long recovery execution delay state. Furthermore, while the flowchart illustrations of the methods depict a specific sequence of operations, this sequence is merely illustrative and not required. Alternative embodiments may perform certain operations in a different order, combine certain operations, overlap certain operations, etc. For example, the determinations at blocks 544, 545, and 560 may optionally be performed in a different order and / or simultaneously, etc.

[0085] Figure 6 This is a block diagram of an embodiment of processor 601, operable to execute an embodiment of user-level monitored access pause thread instruction 605. In some embodiments, Figure 6 The processor is operable to execute Figure 3-5 Any one or more of the methods. For Figure 3-5The aspects and specific optional details described in any of the methods, including, for example, the different possible alternative states and the described manner of transitioning the logic processor to those alternative states and the associated recovery execution latency, as well as the maximum timeout value imposed by the monitoring system software and its described purpose, may also be optionally applied to Figure 6 The method. Alternative sites, Figure 6 The processor can execute similar or different methods. Furthermore, Figure 3-5 Any one or more methods can be derived from and Figure 6 The same, similar or different processors are used to execute the commands.

[0086] During operation, the processor may receive a user-level monitored access pause thread instruction 605 from a first user-level software thread. This instruction may represent a macro instruction, assembly language instruction, machine code instruction, or other instructions or control signals from the processor's instruction set. In some embodiments, the instruction may optionally specify or otherwise indicate an optional user-level specified time or timeout value (e.g., as a source operand). For example, the time or timeout value may optionally be combined with... Figure 3 The time or timeout value discussed in box 345 is similar to or the same. In one aspect, in the absence of prior detection of another resume thread event, the time or timeout value may represent the limit or maximum value of the first given thread to be suspended, as indicated by a user-level monitoring instruction to access the suspended thread. Various different ways of expressing user-level time or timeout values ​​discussed earlier are suitable. As an example, the user-level timeout value may optionally be stored in a specified or indicated register, or provided immediately by the instruction.

[0087] In some embodiments, the user-level monitoring access pause thread instruction 605 may specify or otherwise indicate a given one of a plurality of possible alternative states that the logical processor will transition to when the first user-level thread is paused, although this is not required. It is appropriate for the instruction to indicate alternative states as well as the various previously described alternative states (e.g., not limited to sleep and light sleep states) in the different ways previously discussed. Alternatively, a single alternative state instruction may be optionally supported by the instruction. For example, the instruction's opcode may implicitly indicate a single supported alternative state, making it possible to select among a plurality of such alternative states without requiring additional information associated with the instruction.

[0088] Refer again Figure 6The processor includes a core pipeline 620. In some embodiments, the core pipeline is hardware multithreaded, such as, for example, SMT. The core pipeline includes a decoding unit or decoder 670. The decoding unit can receive and decode user-level detected access pause thread instructions 605. The decoding unit can output one or more relatively low-level instructions or control signals (e.g., one or more microinstructions, microoperations, microcode entry points, decoded instructions or control signals, etc.) that reflect, represent, and / or derive from relatively high-level user-level detected access pause thread instructions. In some embodiments, the decoding unit may include one or more input structures (e.g., ports, interconnects, interfaces) for receiving instructions, instruction recognition and decoding logic coupled thereto for recognition and decoding, and one or more output structures (e.g., ports, interconnects, interfaces) coupled thereto for outputting lower-level instructions or control signals. The decoding unit can be implemented using various different mechanisms, including but not limited to microcode read-only memory (ROM), lookup tables, hardware implementations, programmable logic arrays (PLAs), and other mechanisms suitable for implementing the decoding unit.

[0089] In some embodiments, the user-level detected access pause thread instruction 605 is not directly provided to the decoding unit, but may optionally be provided using an instruction emulator, converter, transformer, interpreter, or other instruction conversion module. Various types of instruction conversion modules may be implemented in software, hardware, firmware, or a combination thereof. In some embodiments, the instruction conversion module may be located external to the processor, such as, for example, on a separate die and / or in memory (e.g., as a static, dynamic, or runtime emulation module). As an example, the instruction conversion module may receive the user-level detected access pause thread instruction 605, which may belong to a first instruction set, and may emulate, convert, transform, interpret, or otherwise convert the user-level detected access pause thread instruction 605 into one or more corresponding intermediate instructions or control signals, which may belong to a second, different instruction set. The one or more intermediate instructions or control signals of the second instruction set may be provided to a decoding unit (e.g., decoding unit 670), which may decode them into one or more lower-level instructions or control signals executable by the processor's native hardware (e.g., one or more execution units).

[0090] Refer again Figure 6The thread pause / resume unit 671 is coupled to the decoding unit 670. The thread pause / resume unit may represent an execution unit for executing instruction 605 and / or may be simply referred to herein as an execution unit. As shown, the thread pause / resume unit or execution unit may be coupled to the decoding unit via other intermediate components, such as, for example, a first set of optional thread-partitionable resources 625. The first set of optional thread-partitionable resources may optionally be similar to or the same as thread-partitionable resource 225. A second set of optional thread-partitionable resources 628 may be coupled to the output of the execution unit. This optional second set may optionally be similar to or the same as thread-partitionable resource 229. The thread pause / resume unit may receive one or more decoded or otherwise converted instructions or control signals representing user-level monitored access to pause thread instruction 605 and / or derived therefrom. These control signals may potentially indicate or suggest alternative states to enter (e.g., in some embodiments, a sleep state or a lighter sleep state). The thread pause / resume unit may also receive optional user-level time or timeout values ​​if optional user-level time or timeout values ​​are used in a particular implementation.

[0091] The thread pause / resume unit may include specific or concrete logic operable to execute the user-level monitoring access pause thread instruction 605. The thread pause / resume unit and / or any component shown or described herein may be implemented in hardware (e.g., integrated circuits, transistors, or other circuit elements), firmware (e.g., ROM, EPROM, flash memory, or other persistent or non-volatile memory and microcode, microinstructions, or other low-level instructions stored therein), or various combinations thereof, potentially / optionally combined with some software (e.g., higher-level instructions stored in memory). In some embodiments, the thread pause / resume unit and / or any component shown or described herein may optionally include only hardware and / or firmware without any software. The thread pause / resume unit may be operable to pause a first user-level software thread from which instruction 605 has been received in response to and / or as a result of the user-level monitoring access pause thread instruction 605 (e.g., in response to one or more instructions or control signals decoded from the instruction). In some embodiments, prior to suspending the thread, the thread pause / resume unit may optionally be operable in response to the instruction to determine whether address monitor logic is activated (e.g., optionally as previously combined). Figure 3 (as described in box 342) and / or ensure that one or more other optional conditions are met beforehand, although this is not required. For example, this can be done by an execution unit and / or processor that exchanges signals or other communications with the address monitor logic.

[0092] The thread pause / resume unit may also be operable in response to and / or as a result of instruction 605 to transition a logical processor (e.g., an SMT hardware thread of core pipeline 620) on which a thread was previously running to an indicated alternative state. In some embodiments (e.g., in a lighter sleep state (e.g., C0.1 state) or optionally even a lighter sleep state), in order to pause a thread, the thread pause / resume unit may transition to a lower-latency resumption execution state (e.g., primarily signaling the core pipeline to stop executing the thread, thereby allowing shared resources to be exclusively used by one or more other threads sharing the same resources, without any merging / combination of partitionable resources). In some embodiments, such an alternative state may optionally be the only state implemented for the instruction. In such cases, the thread pause / resume unit may not need to include optional pipeline dump cleanup logic 673 or optional partitioning / annealing unit 674.

[0093] Alternatively, in other embodiments (e.g., where one or more of the following states are optionally supported: sleep (e.g., C0.2 state), deeper sleep, or C1 or stopped processor state), the thread pause / resume unit may optionally transition the logical processor to a longer-delayed resume execution alternative state. For example, this may include signaling the core pipeline to terminate the execution of a thread and allowing shared resources to be exclusively used by one or more other threads sharing the same resources, and also reconfiguring (e.g., merging or combining) at least some partitionable resources (e.g., a first set of optional thread partitionable resources 625 and / or a second set of optional thread partitionable resources 628) for use by these one or more other threads. In such cases, the thread pause / resume unit may include optional pipeline dump clearing logic 673 and optional partitioning / annealing unit 674. The optional pipeline dump clearing unit may be operable in response to an instruction to dump clearing or drain the core pipeline to clear all instructions. As shown, the optional pipeline dump clearing unit may be operable to signal other components of the pipeline.

[0094] Once the pipeline has been dumped or emptied, optional partitioning / annealing units can operate to merge, anneal, or otherwise combine at least some partitionable resources (e.g., first group 625 and / or second group 628) previously dedicated to the first user-level thread, so that one or more other threads can use these resources while the first user-level thread is suspended. As shown, optional partitioning / annealing units can operate to signal the first and / or second groups of optional thread partitionable resources. As an example, this may include first evacuating instructions from queues, storage buffers, reordering buffers, and the like, and then combining the entries of the queues, storage buffers, and reordering buffers for use by one or more other threads besides the first user-level thread.

[0095] Once the first user-level thread has been suspended, the thread resumption activation unit 675 may be operable in response to instructions to monitor or detect one or more types of events or conditions (e.g., as desired for a particular implementation) that will trigger or cause the resumption of the first user-level thread. As shown, the thread resumption activation unit may include a monitored access detection unit 676. The monitored access detection unit is operable to monitor and / or observe and / or detect indications 638 of access to a monitored address. As an example, this may be combined with previously... Figure 3 The various methods described in box 338 are used to provide access to the monitored address indication. If such an indication is detected, the monitored access detection unit and / or recovery thread activation unit can initiate the recovery of the first user-level thread.

[0096] The thread resumption activation unit may optionally include an event detection unit 677. The optional event detection unit is operable to monitor and / or observe and / or detect one or more other different types of events 679 that may trigger the resumption of the first user-level thread. Whether any such event can trigger the resumption of the first user-level thread is optional for a particular implementation. In some embodiments, possible examples of events that may optionally trigger the resumption of the first user-level thread include non-maskable interrupts (NMIs), system management interrupts (SMIs), debug exceptions, machine check exceptions, start signals, reset signals, certain types of external interrupts (if they are to be delivered to software), events that change address translation, or various combinations thereof. If such an event is detected, the event detection unit and / or the thread resumption activation unit may initiate the resumption of the first user-level thread.

[0097] The thread resumption activation unit may optionally include a pause time monitor unit 678. The optional pause time monitor unit is operable to monitor the time during which the first user-level thread has been paused (relative to one or more of an optional user-level time or timeout value 645 and an optional time or timeout value 660 imposed by the monitoring system software). As mentioned above, the user-level time or timeout value 645 may optionally be indicated by instructions. The optional time or timeout value imposed by the monitoring system software may be similar to the previously combined... Figure 5 The time or timeout value described in box 560 can be optionally used in a similar manner. As an example, the time or timeout value 660 imposed by this monitoring system software can optionally be stored in a processor control register (e.g., a model-specific register). If it is determined that the time or timeout value 660 imposed by the monitoring system software has expired, such an indication 661 can optionally be stored in storage location 699. For example, this can be done as follows: Figure 5 It shall be executed as described in box 561. If it is determined that either the time or the timeout value of the optional implementation has expired, the pause time monitor unit and / or the resume thread activation unit may initiate the resumption of the first user-level thread.

[0098] Upon detection of any of the aforementioned thread resumption conditions or other conditions expected for a particular implementation, the thread pause / resume unit 672 is operable to resume the first user-level thread in response to an instruction. If previously partitioned and abandoned partitionable resources need to be repartitioned, the optional pipeline dump clearing unit 672 is operable to clear all instructions in response to dump clearing or draining the core pipeline. Once the pipeline has been dump cleared or drained, the optional partitioning / annealing unit 674 is operable to repartition these partitionable resources (e.g., any of the previously annealed first set 625 and / or second set 628) so that the first user-level thread, which is about to be awakened, can once again utilize those resources. The first user-level thread can then be resumed, and further execution of instructions from the first user-level thread can begin.

[0099] To avoid obscuring this description, a relatively simple processor has been shown and described. However, the processor may optionally include other processor components. For example, various different embodiments may include... Figure 9A Various combinations and configurations of the components shown and described in any of / B, 10A / B, and 11. All components of the processor can be coupled together to allow them to operate as intended.

[0100] Figure 7This is a block flowchart of an example embodiment of a method 780 for executing a transaction-memory-compatible user-level pause thread instruction within a transaction-memory transaction to pause a first user-level thread without aborting the transaction-memory transaction. In some embodiments, the method may allow the first user-level thread to resume in response to a transaction-memory-compatible user-level pause thread instruction or due to aborting the transaction-memory transaction by the processor's transaction-memory logic. In various embodiments, the method may be performed by a processor, an instruction processing device, a digital logic device, or an integrated circuit. In some embodiments, Figure 7 The method can be derived from Figure 6 The processor to execute and / or Figure 6 Execute within the processor, Figure 6 The processor may optionally include transaction memory logic to support transaction memory. This article focuses on... Figure 6 The components, features, and specific optional details described for the processor are also optionally applied. Figure 7 The method. Alternative sites, Figure 7 The method can be executed and / or performed within similar or different processors or devices (e.g., a processor or device with optionally omitted monitor access detection unit 676 and / or optionally omitted logic for detecting access to memory addresses). Furthermore, Figure 6 The processor can execute with Figure 7 The methods are the same, similar, or different.

[0101] Transaction memory is sometimes also referred to as transaction execution. Transaction memory represents a method for controlling parallel access to shared data by different entities (e.g., logical processors), which can help reduce the need for locks. For some embodiments, a suitable example of transaction memory is a restricted transaction memory (RTM) form of transaction memory in the form of Intel® Transaction Synchronization Extensions (Intel® TSX), but the scope of the invention is not limited thereto. In some embodiments, a transaction memory as described herein may have any one or more (or optionally substantially all) of the characteristics of an RTM form of transaction memory, but the scope of the invention is not limited thereto. Other forms of transaction memory are also suitable.

[0102] The processor, integrated circuit, or other device executing this method may have transaction memory logic. Hardware, firmware, combinations thereof, and combinations of hardware and / or firmware and software can be used to implement different forms of transaction memory, such as pure hardware transaction memory (HTM), unbounded transaction memory (UTM), and hardware-supported (e.g., accelerated) software transaction memory (STM) (hardware-supported STM). As an example, the processor may have transaction buffers or other storage devices, transaction start logic for initiating a transaction, transaction conflict detection logic for detecting transaction abort conditions, transaction abort logic for aborting a transaction, transaction end logic for ending a transaction, and so on.

[0103] refer to Figure 7 The method includes receiving a transaction start instruction at block 781 and initiating a transaction memory transaction. A specific example of a suitable transaction start instruction is the XBEGIN instruction for transaction memory in RTM form, but the scope of the invention is not limited thereto. The XBEGIN instruction is operable at execution to cause the processor to transition execution to transaction memory (e.g., open transaction memory) if it has not already transitioned to transaction memory. The XBEGIN instruction may also indicate the instruction address of a processor for disposing of an aborted transaction (if the aborted transaction occurs). In other embodiments, the transaction start instruction may not be a specific XBEGIN instruction, but may have any one or more (or optionally all) of the features of the XBEGIN instruction, or similar features, potentially combined with additional features. The scope of the invention is not limited to any known transaction start instruction or its operation.

[0104] Groups of instructions and / or operations within a transaction can be executed atomically and transparently by utilizing transactional memory. Atomicity implies that these instructions and / or operations are executed completely or not at all, but not divisibly. Within a transaction, data that would otherwise be protected by locks can only be read, not written non-speculatively within the transaction in a way that would make it globally visible, and may not require actually acquiring locks. If a transactional memory transaction succeeds, writes to data within the transaction via instructions and / or operations can be executed atomically without having acquired locks. However, if a transactional memory transaction fails and / or is aborted, speculative updates to the state can be discarded without ever being visible to other logical processors. Furthermore, data reads within a transaction can also occur atomically without acquiring locks. These reads can represent a set of reads within a transactional memory transaction. If the transactional memory logic detects within the transactional memory transaction that any memory address read within the transaction (e.g., a set of transactional reads) has been modified by another logical processor, the transaction may be aborted because the entire set of reads cannot be acquired atomically. As will be explained further below, this aspect of the transaction memory can be used to monitor multiple memory addresses in conjunction with a pause thread instruction, which must have an associated memory address to be monitored (e.g., this can instead be offloaded to be monitored via the transaction memory).

[0105] Refer again Figure 7 Once a transaction memory transaction has begun (e.g., by executing a transaction start instruction at block 781), the transaction memory logic (e.g., primarily comprising on-die logic of the processor (e.g., hardware and / or firmware)) can begin monitoring and determining at block 790 whether a transaction memory transaction abort condition has been detected. Note that the “fork” at the output of block 781 does not represent an alternative path, but rather a parallel path that can occur together and in parallel, as will be discussed further below. Different types of abort conditions may potentially be supported, as desired for a particular implementation. In some embodiments, a conflicting access (e.g., a write to a set of transaction reads) can represent such a transaction abort condition. If no such abort condition is detected (i.e., “No” is the determination at block 790), the method can repeatedly loop back at block 790 by making such a determination again. In one aspect, the processor and / or its transaction memory logic can monitor for such abort conditions substantially continuously as long as a transaction memory transaction is being executed. If such an abort condition is detected (i.e., "yes" is the determination at box 790), the method can proceed to box 791, where the transaction memory logic can abort the transaction, as will be discussed further below.

[0106] Refer again Figure 7After a transaction start instruction has been executed, and when the transaction memory logic detects an abort condition at block 790, additional instructions for the transaction can be executed. In some embodiments, one or more load instructions can be executed within a transaction to load data from a shared memory location. Load instructions are sometimes also referred to as read instructions or move instructions. As shown in block 782, a first load instruction can be received and executed within a transaction memory transaction, and a first shared memory location or memory address can be loaded. Optionally, other load instructions can be executed similarly to read other shared memory locations or addresses. As shown in block 783, optionally, up to the Nth load instruction can be received and executed within a transaction memory transaction, and the Nth corresponding shared memory location or memory address can be loaded. As an example, in some embodiments, the number of memory locations read can extend from one (or two) to approximately fifty, or from one (or two) to approximately twenty, but the scope of the invention is not limited to any known number. These one or more loads executed within a transaction can represent a so-called set of reads for the transaction.

[0107] Refer again Figure 7 In box 784, a transaction-memory-compatible user-level pause thread instruction can be received within a transaction-memory transaction. Instructions can be received from a first user-level thread, from which the instructions in boxes 781-783 are also received. In box 785, a method can be executed in response to a transaction-memory-compatible user-level pause thread instruction without aborting the transaction-memory transaction. Advantageously, it is permissible to execute transaction-memory-compatible user-level pause thread instructions within a transaction-memory transaction without needing to terminate or abort the transaction-memory transaction and / or without needing to transfer to a supervisory software processor. Conversely, certain other types of pause thread instructions and / or power management instructions may be incompatible with transaction memory and, if executed within a transaction-memory transaction, may cause the transaction-memory transaction to be aborted.

[0108] As shown in box 786, in response to a transaction-memory-compatible user-level pause thread instruction, the execution of a first user-level thread can be paused. Then, in box 787, in response to the transaction-memory-compatible user-level pause thread instruction, a determination can be made as to whether a thread resumption condition has been detected. Note that the determination at box 787 can be performed simultaneously and in parallel with the determination at box 790. In other words, box 787 can occur substantially continuously in response to a transaction-memory-compatible user-level pause thread instruction (once it has been executed and until it completes), and the determination at box 790 can be performed substantially continuously once transaction execution has begun, and can continue until transaction execution is aborted or terminated. In box 787, if such a thread resumption condition has not yet been detected (i.e., "No" is the determination at box 787), the method can continue checking. Otherwise, if a thread resumption condition has been detected (i.e., "Yes" is the determination at box 787), the method can proceed to box 788. In box 788, the first user-level thread can be resumed in response to a transaction-memory-compatible user-level pause thread instruction. For example, a thread can resume at the next instruction following a transaction-memory-compatible user-level pause thread instruction. If desired, the method and / or software can then identify that the monitored position has not been modified, and can optionally execute another instance of the transaction-memory-compatible user-level pause thread instruction to pause the thread again, while the position is further monitored by the transaction-memory logic. Alternatively, the method can then proceed to block 789, where a transaction end instruction (e.g., as an example of an XEND instruction) can be received, and the transaction-memory transaction can be committed accordingly.

[0109] The operation of block 785 has been shown and described in a relatively basic form, but operations may optionally be added to it. For example, in some embodiments, the operation at block 785 may include... Figure 3 Any one or more of the operations at blocks 342-346, including their variations and alternatives. In other embodiments, the operation at block 785 may include... Figure 5 Any one or more of the operations at blocks 542-546 and / or 560-561, including their variations and alternatives. In other embodiments, the operation at block 785 may include... Figure 8 Any one or more of the operations of blocks 894-899 (which will be discussed further below), including their variations and alternatives. That is, in some embodiments, combined with Figure 3 The previously described alternative states can optionally be used with user-level pause thread instructions compatible with transaction memory. Furthermore, in some embodiments, combined with... Figure 5The indication in block 561 and the maximum timeout value imposed by the previously described monitoring software discussed in block 560 can optionally be used with user-level pause thread instructions compatible with transaction memory. In some embodiments, block 785 may optionally include an indication of whether an access to the monitored address has been detected (e.g., as described for blocks 344 or 544). In other embodiments, block 785 may optionally omit making such a determination. That is, in some embodiments, there may be no associated memory address monitoring operation as part of this instruction.

[0110] The determination at box 790 can still be performed even after the execution of the first user-level thread resumes at box 788. That is, the determination at box 790 can be performed before, simultaneously with, and after the execution of a transaction-memory compatible user-level pause thread instruction, as long as a transaction-memory transaction is being executed. This determination at box 790 can be separate from and not controlled by the transaction-memory compatible user-level pause thread instruction, but rather by a portion of the transaction memory. In part, the determination at box 790 can determine whether there are any conflicting accesses to memory locations or addresses corresponding to load instructions at boxes 782-783. These can represent a set of reads from a transaction-memory transaction. In some embodiments, a write to, or an attempted write to, any of these shared memory locations in the set of reads from a transaction-memory transaction detected by another logical processor can represent such conflicting accesses that could lead to the abort of the transaction-memory transaction.

[0111] If an abort condition is detected (i.e., "yes" is determined at box 790), such as if a write to any memory address associated with the load instructions of boxes 782-783 is detected, or if an interrupt or some other microarchitectural condition occurs, the method may proceed to box 791. At box 791, the transaction memory logic may cause the transaction memory transaction to abort. Any speculative updates to the architectural state (e.g., the load of boxes 782-783) may be cancelled. Optionally, information about the reason for the abort may be provided (e.g., in a general-purpose register). In some embodiments, this may also terminate the execution of a transaction memory-compatible user-level pause thread instruction and resume the suspended first user-level thread. Note that under such conditions, aborting the transaction memory transaction and resuming the first user-level thread may be performed by the transaction memory logic alone, rather than in response to the execution of a transaction memory-compatible user-level pause thread instruction (e.g., not part of box 785). Control may also typically be transferred to an abort handler (e.g., at the instruction address indicated by the transaction start instruction of box 781). In some embodiments, the processor may anticipate that one of the monitored locations has been modified (e.g., corresponding to boxes 782-783) and may investigate this.

[0112] The load instruction in block 782 and the optional block 783 of the transactional memory transaction can effectively set up or configure the transactional memory logic with memory addresses and / or ranges to be monitored. At least conceptually, when used in this manner, the transactional memory logic can serve as a class of address monitor logic that can be utilized to eliminate the need for separate address monitor logic (e.g., set up by user-level set-monitor-address instructions). Additionally, in some embodiments, the transactional memory logic may optionally / potentially monitor one memory address or range, or optionally / potentially monitor two or more memory addresses or ranges, or optionally / potentially monitor from several to a large number of memory addresses or ranges. Typically, if an access is made to a set of reads associated with any of these one or more memory addresses or ranges, the transactional memory logic can abort the transaction and cause execution to resume. Furthermore, when the transactional memory logic monitors such a write to the set of reads, one or more of the transactional memory-compatible user-level pause-thread instructions can be executed to pause a first user-level thread.

[0113] There are various possible reasons for wanting to monitor multiple memory addresses. The scope of this invention is not limited to any known such reasons. However, to further illustrate certain concepts, a specific example will be described. In this example, software may interact with a network interface card (NIC) that supports multiple incoming queues of messages arriving at different links. The NIC may write different locations in memory to indicate that a message will be received in each of the multiple corresponding incoming queues. A given software thread might want to pause when there is no message in an incoming queue, but might expect to resume when a message is available in one of the incoming queues. This is just one example. In other examples, memory addresses may be monitored for other types of input / output data or for various other reasons.

[0114] In other embodiments, similar to those for... Figure 7 The user-level thread-pause instructions described in boxes 784-785 that are transaction-memory compatible do not necessarily need to be used within a transaction-memory transaction, nor do they necessarily need to be transaction-memory compatible. That is, the use of such instructions within a transaction-memory transaction is optional. Furthermore, transaction-memory compatibility of such instructions is optional. Of course, for example, such instructions can be used to pause a user-level thread while waiting for one or more timeout values ​​(e.g., user-level timeout values ​​and / or timeout values ​​imposed by supervisory software) to expire and / or while waiting for an interrupt and / or other thread-resumption event expected by a particular implementation.

[0115] Figure 8This is a block flowchart of an embodiment of a method 892 for executing optional transaction memory-compatible user-level pause thread instructions. In various embodiments, the method may be performed by a processor, instruction processing device, digital logic device, or integrated circuit. In some embodiments, the method may be performed by… Figure 6 This is executed by the processor. This article is for... Figure 6 The components, features, and specific optional details described for the processor may also be optionally applied to Figure 8 The method. Alternative sites, Figure 8 The method can be executed and / or performed within similar or different processors or devices (e.g., processors or devices that optionally omit the monitor access detection unit 676 and / or optionally omit any logic for detecting access to any memory address). Furthermore, Figure 6 The processor can execute with Figure 8 The methods are the same, similar, or different.

[0116] refer to Figure 8 In block 893, a user-level pause thread instruction compatible with optional transaction memory can be received. In some embodiments, this instruction may optionally be transaction-memory compatible. In other embodiments, this is not required. In some embodiments, the instruction may optionally specify or otherwise indicate a user-level timeout value. For example, this may optionally be combined as previously stated. Figure 3 As described in box 341, this includes its variations and alternatives. In some embodiments, the instructions may specify or otherwise indicate one of a plurality of possible alternative states. For example, this may optionally be combined as previously described. Figure 3 As described in box 341, this includes variations and alternatives. As an example, this could include the previously described lighter sleep states and sleep states.

[0117] In box 894, execution of the first user-level thread can be paused, and the logical processor on which the first user-level thread was running can be transitioned to the indicated alternative state. For example, this can optionally be combined as previously described. Figure 3 It is accomplished as described in box 343, including its variations and alternatives, and includes the use of any previously described alternative states (e.g., lighter sleep, sleep, C0.1, C0.2, etc.).

[0118] In blocks 895-897, a determination may be optionally made as to whether to resume execution (e.g., of the first user-level thread). Specifically, in block 895, a determination may be optionally made as to whether an interrupt or other thread resumption event has been detected. For example, in various embodiments, nonmaskable interrupts (NMIs), system management interrupts (SMIs), debug exceptions, machine check exceptions, start signals, reset signals, certain types of external interrupts (if they are to be delivered to software), events that change address translations, and various combinations thereof may optionally prompt the first user-level thread to resume. Because such events may involve transitioning execution to the appropriate privilege level handler, many such events are typically handled by privileged software and thus resume execution. In other embodiments, certain types of interrupts (e.g., input-output interrupts, interrupts from on-die hardware accelerators, other interrupts suitable for user-level code) may optionally be provided directly to and handled by the user-level application without transitioning from user-level privilege to a higher privilege level, but this is not necessary. In such events, execution may potentially resume via the same user-level thread or a different user-level thread. If a recovery event of one of these types has been detected (i.e., "Yes" is the determination at box 895), the method can proceed to box 899. Otherwise, if a recovery event has not been detected (i.e., "No" is the determination), the method can proceed to box 896.

[0119] In box 896, it is possible to optionally determine whether an optional user-level timeout value, optionally indicated by a transaction-memory-compatible user-level pause thread instruction, has expired. For example, this can optionally be combined as previously described. Figure 3 The method is performed as described in box 345, including its variations and alternatives. If the user-level timeout value has expired (i.e., "yes" is confirmed), the method may proceed to box 899. Otherwise, if the user-level timeout value has not expired (i.e., "no" is confirmed), the method may proceed to box 897.

[0120] In box 897, it is optional to determine whether a timeout value imposed by the optional monitoring system software has expired. For example, this can be optionally combined as previously stated. Figure 5 The method can be performed as described in box 560, including its variations and alternatives. If the timeout value imposed by the monitoring system software has not expired (i.e., "No" is determined), the method can revisit box 895, where another round of determination can be made, optionally in a continuous loop until an exit condition from the loop is detected. Alternatively, if the timeout value has expired (i.e., "Yes" is determined), the method can proceed to box 898.

[0121] In box 898, an indication can be provided that the suspension of the first user-level thread is ending due to the expiration of the maximum time or timeout value imposed by the monitoring system software and / or the privilege level. For example, this can optionally be combined as previously stated. Figure 5 It can be accomplished as described in box 561, including its variations and alternatives.

[0122] In box 899, execution of the first user-level thread can be resumed from the logical processor in the indicated alternative state. For example, this can optionally be combined as previously described. Figure 3 Box 346 and / or Figure 5 It can be accomplished as described in box 546, including its variations and alternatives.

[0123] Note that in Figure 8 In some embodiments, optional transaction memory-compatible user-level pause thread instructions may optionally omit the need for indication of monitoring access to memory locations (e.g., as previously stated for...). Figure 3 (As described in box 344). Of course, in some embodiments, it is not necessary for the instructions to have any associated monitored address or any such address monitoring. Of course, as an example, transactional memory logic may optionally be used to monitor access to one or more addresses (e.g., as for...). Figure 7 (As discussed), but this is not necessary. Furthermore, as another example, a thread can be paused without waiting for a memory access to occur, but simply wait for one or more timeout values, wait for an interrupt to occur (e.g., optionally, a user-level interrupt can be delivered directly to user-level code), or a combination of unsupervised memory addresses.

[0124] Method 892 has been shown and described in a relatively basic form, but operations may optionally be added to and / or removed from the method. For example, any one or more optional determinations at blocks 895-897 may optionally be removed. Furthermore, while the flowchart illustrations of the method show a specific order of operations, this order is merely illustrative and not required. Alternative embodiments may perform some operations in a different order, combine some operations, overlap some operations, etc. For example, the determinations at blocks 895-897 may optionally be performed in a different order and / or simultaneously, etc.

[0125] Demonstration core architecture, processor, and computer architecture

[0126] Processor cores can be implemented in different ways, for different purposes, and in different processors. For example, implementations of such cores may include: 1) general-purpose ordered cores intended for general-purpose computing; 2) high-performance general-purpose out-of-order cores intended for general-purpose computing; and 3) dedicated cores intended primarily for graphics and / or scientific (throughput) computing. Implementations of different processors may include: 1) CPUs, including one or more general-purpose ordered cores and / or one or more general-purpose out-of-order cores intended for general-purpose computing; and 2) coprocessors, including one or more dedicated cores intended primarily for graphics and / or scientific (throughput) computing. Such different processors result in different computer system architectures, which may include: 1) coprocessors on a separate chip from the CPU; 2) coprocessors on a separate die in the same package as the CPU; 3) coprocessors on the same die as the CPU (in this case, such coprocessors are sometimes referred to as dedicated logic, such as integrated graphics and / or scientific (throughput) logic, or dedicated cores); and 4) systems-on-a-chip, which may include the described CPU (sometimes referred to as one or more application cores or one or more application processors), the aforementioned coprocessors, and additional functionality on the same die. Following the description of the demonstrator processor and computer architecture, the demonstrator core architecture will be described next.

[0127] Demonstration core architecture

[0128] Ordered and disordered kernel diagrams

[0129] Figure 9A This is a block diagram illustrating both an exemplary ordered pipeline and an exemplary register renaming, out-of-order release / execution pipeline, according to embodiments of the present invention. Figure 9B This is a block diagram illustrating an exemplary embodiment of an ordered architecture core and an exemplary register renaming, out-of-order release / execution architecture core to be included in a processor, according to embodiments of the present invention. Figure 9A The solid boxes in -B indicate ordered pipelines and ordered cores, while the optional dashed boxes indicate register renaming, out-of-order release / execution pipelines, and cores. The out-of-order aspect is described under the assumption that the ordered aspect is a subset of the out-of-order aspect.

[0130] exist Figure 9A In the processor pipeline 900, there are a fetch phase 902, a length decoding phase 904, a decoding phase 906, an allocation phase 908, a renaming phase 910, a scheduling (also known as dispatch or release) phase 912, a register read / memory read phase 914, an execution phase 916, a write-back / memory write phase 918, an exception handling phase 922, and a commit phase 924.

[0131] Figure 9BThe display processor core 990 includes a front-end unit 930 coupled to an execution engine unit 950, both of which are coupled to a memory unit 970. Core 990 can be a Reduced Instruction Set Computing (RISC) core, a Complex Instruction Set Computing (CISC) core, a Very Long Instruction Word (VLIM) core, or a hybrid or alternative core type. Alternatively, core 990 can be a dedicated core, such as a network or communication core, a compression engine, a coprocessor core, a General Purpose Graphics Processing Unit (GPGPU) core, a graphics core, or the like.

[0132] Front-end unit 930 includes a branch prediction unit 932 coupled to instruction cache unit 934, unit 934 coupled to instruction translation lookup buffer (TLB) 936, which is coupled to instruction fetch unit 938, which is coupled to decoding unit 940. Decoding unit 940 (or decoder) can decode instructions and generate one or more micro-operations, microcode input points, microinstructions, other instructions, or other control signals as outputs, which are decoded from the original instruction or otherwise reflect or are derived from the original instruction. Decoding unit 940 can be implemented using various different mechanisms. Examples of suitable mechanisms include, but are not limited to, lookup tables, hardware implementations, programmable logic arrays (PLAs), microcode read-only memory (ROM), etc. In one embodiment, core 990 includes microcode ROM or other media (e.g., in decoding unit 940 or otherwise within front-end unit 930) storing microcode for certain macro instructions. Decoding unit 940 is coupled to rename / allocator unit 952 in execution engine unit 950.

[0133] The execution engine unit 950 includes a rename / allocator unit 952 coupled to a set of one or more scheduler units 956, including a retirement unit 954. The one or more scheduler units 956 represent any number of different schedulers, including reservation stations, central instruction windows, etc. The one or more scheduler units 956 are coupled to one or more physical register file units 958. Each of the one or more physical register file units 958 represents one or more physical register files, with different files storing one or more different data types, such as scalar integers, scalar floating-point numbers, compressed integers, compressed floating-point numbers, vector integers, vector floating-point numbers, status (e.g., an instruction pointer as the address of the next instruction to be executed), etc. In one embodiment, the one or more physical register file units 958 include vector register units, write mask register units, and scalar register units. These register units can provide architectural vector registers, vector mask registers, and general-purpose registers. One or more physical register file units (one or more) 958 are overlapped by a retirement unit 954 to illustrate various ways in which register renaming and out-of-order execution can be implemented (e.g., using one or more reorder buffers and one or more retirement register files; using one or more future files, one or more history buffers and one or more retirement register files; using register mappings and register pools, etc.). The retirement unit 954 and one or more physical register file units (one or more) 958 are coupled to one or more execution clusters 960. The one or more execution clusters 960 include a set of one or more execution units 962 and a set of one or more memory access units 964. The execution units 962 can perform various operations (e.g., shift, addition, subtraction, multiplication) and perform operations on various types of data (e.g., scalar floating-point, compressed integer, compressed floating-point, vector integer, vector floating-point). While some embodiments may include multiple execution units dedicated to a particular function or set of functions, other embodiments may include only multiple execution units that perform all functions or a single execution unit. One or more scheduler units 956, one or more physical register file units (one or more) 958, and one or more execution clusters 960 are shown as possibly multiple because some embodiments create separate pipelines for certain types of data / operations (e.g., scalar integer pipelines, scalar floating-point / compressed integer / compressed floating-point / vector integer / vector floating-point pipelines, and / or memory access pipelines, each with its own scheduler unit, one or more physical register file units, and / or execution clusters - and in the case of separate memory access pipelines, some embodiments are implemented in which the execution cluster of only this pipeline has one or more memory access units 964).It should also be understood that, when using individual pipelines, one or more of these pipelines can be released / executed out of order, while the rest of the pipelines are ordered.

[0134] A set of memory access units 964 is coupled to memory unit 970, which includes a data TLB unit 972 coupled to data cache unit 974, which is coupled to level 2 (L2) cache unit 976. In one exemplary embodiment, memory access unit 964 may include a load unit, a memory address unit, and a memory data unit, each of which is coupled to the data TLB unit 972 in memory unit 970. Instruction cache unit 934 is also coupled to level 2 (L2) cache unit 976 in memory unit 970. L2 cache unit 976 is coupled to one or more other levels of cache and ultimately coupled to main memory.

[0135] By example, the demonstration register renaming, out-of-order release / execution core architecture can be implemented in pipeline 900 as follows: 1) Instruction fetch 938 executes fetch phase 902 and length decoding phase 904; 2) Decoding unit 940 executes decoding phase 906; 3) Rename / allocator unit 952 executes allocation phase 908 and rename phase 910; 4) One or more scheduler units 956 execute scheduling phase 912; 5) One or more physical register file units 958 and memory unit 970 execute register read / memory read phase 914; execution cluster 960 executes execution phase 916; 6) Memory unit 970 and one or more physical register file units 958 execute write-back / memory write phase 918; 7) Various units may be involved in exception handling phase 922; and 8) Retirement unit 954 and one or more physical register file units 958 execute commit phase 924.

[0136] Core 990 may support one or more instruction sets (e.g., the x86 instruction set (with some extensions added in later versions), the MIPS instruction set of MIPS Technologies, Sunnyvale, California, or the ARM instruction set of ARM Holdings, Sunnyvale, California (with optional additional extensions such as NEON)), including one or more instructions described herein. In one embodiment, Core 990 includes logic supporting compressed data instruction set extensions (e.g., AVX1, AVX2), thereby allowing operations used by many multimedia applications to be performed using compressed data.

[0137] It should be understood that a core may support multithreading (the execution of two or more parallel operations or a set of threads) and may do so in a variety of ways, including time-slice multithreading, simultaneous multithreading (where a single physical core provides a logical core for each thread that the physical core is performing multithreading on simultaneously), or a combination thereof (e.g., time-slice fetching and decoding and subsequent simultaneous multithreading as in Intel® Hyper-Threading Technology).

[0138] Although register renaming is described in the context of out-of-order execution, it should be understood that register renaming can also be used in ordered architectures. While the illustrated embodiment of the processor also includes separate instruction and data cache units 934 / 974 and a shared L2 cache unit 976, alternative embodiments may have a single internal cache for both instructions and data, such as, for example, a Level 1 (L1) internal cache, or multiple levels of internal caches. In some embodiments, the system may include a combination of internal caches and external caches outside the core and / or processor. Alternatively, all caches may be external to the core and / or processor.

[0139] Specific demonstration ordered kernel architecture

[0140] Figure 10A -B illustrates a more specific example of an ordered core architecture, which will be one of several logic blocks in the chip (including other cores of the same type and / or different types). Depending on the application, the logic block communicates with some fixed-function logic, memory I / O interfaces, and other necessary I / O logic via a high-bandwidth interconnect network (e.g., a ring network).

[0141] Figure 10A This is a block diagram of a single processor core according to an embodiment of the present invention, along with its connection to an on-die interconnect network 1002 and a local subset of its Level 2 (L2) cache 1004. In one embodiment, the instruction decoder 1000 supports the x86 instruction set with compressed data instruction set extensions. The L1 cache 1006 allows low-latency access to cache memory in scalar and vector units. While in one embodiment (for design simplification), scalar unit 1008 and vector unit 1010 use separate register sets (scalar register 11012 and vector register 1014, respectively), and data transferred between them is written to memory and then read back from the Level 1 (L1) cache 1006, alternative embodiments of the present invention may use different schemes (e.g., using a single register set, or including a communication path that allows data transfer between two register sets without write-back and read-back).

[0142] The local subsets of L2 cache 1004 are part of the global L2 cache, which is divided into separate local subsets, one for each processor core. Each processor core has a direct access path to its own local subset of L2 cache 1004. Data read by a processor core is stored in its L2 cache subset 1004 in parallel with other processor cores accessing their own local L2 cache subsets and can be accessed quickly. Data written by a processor core is stored in its own L2 cache subset 1004 and is dumped and cleared from other subsets if necessary. The ring network ensures the coherence of shared data. The ring network is bidirectional, allowing agents such as processor cores, L2 caches, and other logic blocks to communicate with each other within the chip. Each ring data path is 1012 bits wide in each direction.

[0143] Figure 10B This is an embodiment of the content of the present invention. Figure 10A An expanded diagram of some of the processor cores. Figure 10B This includes the L1 data cache 1006A portion of L1 cache 1004, and further details regarding vector unit 1010 and vector register 1014. Specifically, vector unit 1010 is a 16-wide vector processing unit (VPU) (see 16-wide ALU 1028) that executes one or more instructions, including integer, single-precision floating-point, and double-precision floating-point instructions. The VPU supports stirring of register inputs via stirring unit 1020, numerical conversion via value conversion units 1022A-B, and copying of memory inputs via copy unit 1024. Write mask register 1026 allows for the writing of predicted vectors.

[0144] Processor with integrated memory controller and graphics

[0145] Figure 11 This is a block diagram of a processor 1100, which may have more than one core, an integrated memory controller, and integrated graphics, according to an embodiment of the present invention. Figure 11 The solid box shows a processor 1100 having a single core 1102A, a system agent 1110, and a collection of one or more bus controller units 1116, while the optional dashed box shows an alternative processor having a collection of multiple cores 1102A-N, one or more integrated memory controller units (one or more) 1114 of system agent units 1110, and dedicated logic 1108.

[0146] Therefore, different implementations of processor 1100 may include: 1) a CPU, wherein dedicated logic 1108 is integrated graphics and / or scientific (throughput) logic (which may include one or more cores), and cores 1102A-N are one or more dedicated cores (e.g., general-purpose ordered cores, general-purpose out-of-order cores, or a combination of both); 2) a coprocessor, wherein cores 1102A-N are multiple dedicated cores intended primarily for graphics and / or scientific (throughput); and 3) a coprocessor, wherein cores 1102A-N are a large number of general-purpose ordered cores. Thus, processor 1100 may be a general-purpose processor, coprocessor, or dedicated processor, such as, for example, a network or communication processor, a compression engine, a graphics processor, a GPGPU (General-Purpose Graphics Processing Unit), a high-throughput integrated many-core (MIC) coprocessor (including 30 or more cores), an embedded processor, or the like. The processor may be implemented on one or more chips. Processor 1100 may be part of one or more substrates using any of the multiple processing technologies such as BiCMOS, CMOS, or NMOS, and / or may be implemented on one or more substrates.

[0147] The memory hierarchy includes one or more levels of cache within the core, a collection of one or more shared cache units 1106, and external memory (not shown) coupled to a set of integrated memory controller units 1114. The collection of shared cache units 1106 may include one or more intermediate-level caches, last-level caches (LLCs), and / or combinations thereof, such as L2, L3, L4, or other levels of cache. While in one embodiment, a ring-based interconnect unit 1112 interconnects the integrated graphics logic 1108, the collection of shared cache units 1106, and the system proxy unit 1110 / one or more integrated memory controller units 1114, alternative embodiments may use any number of known techniques for interconnecting such units. In one embodiment, coherence is maintained between one or more cache units 1106 and cores 1102A-N.

[0148] In some embodiments, one or more cores 1102A-N are capable of multithreading. System agent 1110 includes those components that coordinate and operate cores 1102A-N. System agent unit 1110 may include, for example, a power control unit (PCU) and a display unit. The PCU may be or include the logic and components required for regulating the power state of cores 1102A-N and integrated graphics logic 1108. The display unit is used to drive one or more externally connected displays.

[0149] The 1102A-N cores can be homogeneous or heterogeneous in terms of their instruction set architecture; that is, two or more 1102A-N cores can execute the same instruction set, while other cores can only execute a subset of that instruction set or a different instruction set.

[0150] Demonstration computer architecture

[0151] Figures 12-15 This is a block diagram illustrating a computer architecture. Other system designs and configurations well-known in the art for laptops, desktop computers, handheld PCs, personal digital assistants, engineering workstations, servers, network devices, network hubs, switches, embedded processors, digital signal processors (DSPs), graphics devices, video game devices, set-top boxes, microcontrollers, cellular phones, portable media players, handheld devices, and various other electronic devices are also suitable. Generally, a wide variety of systems or electronic devices capable of incorporating processors and / or other execution logic disclosed herein are generally suitable.

[0152] Now refer to Figure 12 The diagram illustrates a block diagram of a system 1200 according to one embodiment of the present invention. System 1200 may include one or more processors 1210, 1215 coupled to a controller hub 1220. In one embodiment, the controller hub 1220 includes a graphics memory controller hub (GMCH) 1290 and an input / output hub (IOH) 1250 (which may be on a separate chip); the GMCH 1290 includes memory and a graphics controller, to which a memory 1240 and a coprocessor 1245 are coupled; the IOH 1250 couples an input / output (I / O) device 1260 to the GMCH 1290. Alternatively, one or both of the memory and the graphics controller may be integrated within the processor (as described herein), with the memory 1240 and the coprocessor 1245 directly coupled to the processor 1210, and the controller hub 1220 together with the IOH 1250 on a single chip.

[0153] The optional nature of the additional processor 1215 is in Figure 12 The numbers are indicated by dashed lines. Each processor 1210, 1215 may include one or more processing cores described herein, and may be a version of processor 1100.

[0154] The memory 1240 may be, for example, dynamic random access memory (DARAM), phase-change memory (PCM), or a combination of both. In at least one embodiment, the controller hub 1220 communicates with one or more processors 1210, 1215 via a multi-branch bus such as a front-side bus (FSB), a point-to-point interface such as a fast path interconnect (QPI), or a similar connection 1295.

[0155] In one embodiment, the coprocessor 1245 is a dedicated processor, such as, for example, a high-throughput MIC processor, a network or communications processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, or the like. In one embodiment, the controller hub 1220 may include an integrated graphics accelerator.

[0156] There can be a variety of differences between physical resources 1210 and 1215 in terms of a spectrum of metrics of merit, including architectural characteristics, microarchitectural characteristics, thermal characteristics, power consumption characteristics, and so on.

[0157] In one embodiment, processor 1210 executes instructions that control general-type data processing operations. Embedded within these instructions may be coprocessor instructions. Processor 1210 identifies these coprocessor instructions as belonging to a type that should be executed by an attached coprocessor 1245. Accordingly, processor 1210 issues these coprocessor instructions (or control signals representing coprocessor instructions) to coprocessor 1245 on a coprocessor bus or other interconnect. One or more coprocessors 1245 receive and execute the received coprocessor instructions.

[0158] Now refer to Figure 13 The figure shows a block diagram of a first, more specific, exemplary system 1300 according to an embodiment of the present invention. Figure 13 The multiprocessor system 1300 shown is a point-to-point interconnect system and includes a first processor 1370 and a second processor 1380 coupled via a point-to-point interconnect 1350. Each processor 1370 and 1380 may be a version of processor 1100. In one embodiment of the invention, processors 1370 and 1380 are processors 1210 and 1215, respectively, and coprocessor 1338 is coprocessor 1245. In another embodiment, processors 1370 and 1380 are processor 1210 and coprocessor 1245, respectively.

[0159] Processors 1370 and 1380 are shown to include integrated memory controller (IMC) units 1372 and 1382, respectively. Processor 1370 also includes point-to-point (PP) interfaces 1376 and 1378 as part of its bus controller unit; similarly, the second processor 1380 includes PP interfaces 1386 and 1388. Processors 1370 and 1380 can exchange information via point-to-point (PP) interface 1350 using PP interface circuits 1378 and 1388. Figure 13As shown, IMC 1372 and 1382 couple the processor to the corresponding memory, namely memory 1332 and memory 1334, which may be part of the main memory locally attached to the corresponding processor.

[0160] Processors 1370 and 1380 can each exchange information with chipset 1390 via separate PP interfaces 1352 and 1354 using point-to-point interface circuits 1376, 1394, 1386, and 1398. Chipset 1390 can optionally exchange information with coprocessor 1338 via high-performance interface 1339. In one embodiment, coprocessor 1338 is a dedicated processor, such as, for example, a high-throughput MIC processor, a network or communications processor, a compression engine, a graphics processor, a GPGPU, an embedded processor, or the like.

[0161] A shared cache (not shown) may be included in the processor or outside the two processors and connected to the processors via a PP interconnect, such that if the processors are in a low-power mode, the local cache information of any one or two processors may be stored in the shared cache.

[0162] Chipset 1390 may be coupled to first bus 1316 via interface 1396. In one embodiment, first bus 1316 may be a peripheral component interconnect (PCI) bus, or a bus such as a PCI Express bus or another third-generation I / O interconnect bus, although the scope of the present invention is not so limited.

[0163] like Figure 13 As shown, various I / O devices 1314 may be coupled to the first bus 1316 along with a bus bridge 1318 that couples the first bus 1316 to the second bus 1320. In one embodiment, one or more additional processors(s) 1315, such as a coprocessor, a high-throughput MIC processor, a GPGPU, an accelerator (such as, for example, a graphics accelerator and digital signal processing (DSP) unit), a field-programmable gate array, or any other processor, are coupled to the first bus 1316. In one embodiment, the second bus 1320 may be a low pin count (LPC) bus. In one embodiment, various devices may be coupled to the second bus 1320, such as a keyboard and / or mouse 1322, a communication device 1327, and a storage unit 1328, such as a disk drive or other mass storage device, which may include instruction / code and data 1330. Additionally, audio I / O 1324 may be coupled to the second bus 1320. Note that other architectures are possible. For example, the system may implement a multi-branch bus or other such architecture, instead of... Figure 13 A peer-to-peer architecture.

[0164] Now refer to Figure 14 The diagram shown is a block diagram of a second, more specific, exemplary system 1400 according to an embodiment of the present invention. Figure 13 and 14 The same elements in the figure use the same reference numerals, and have been removed from Figure 14 The middle part is omitted Figure 13 To avoid blurring certain aspects Figure 14 Other aspects.

[0165] Figure 14 Processors 1370 and 1380 are shown to include integrated memory and I / O control logic (“CL”) 1372 and 1382, respectively. Therefore, CL 1372 and 1382 include an integrated memory controller unit and I / O control logic. Figure 14 This shows that not only are the memories 1332 and 1334 coupled to CLs 1372 and 1382, but the I / O device 1414 is also coupled to the control logic 1372 and 1382. The legacy I / O device 1415 is coupled to the chipset 1390.

[0166] Now refer to Figure 15 The diagram shown is a block diagram of a SoC 1500 according to an embodiment of the present invention. Figure 11 Similar elements within the same text use the same labeling. Furthermore, dashed boxes indicate optional features related to more advanced SoCs. Figure 15 In this embodiment, one or more interconnect units 1502 are coupled to: an application processor 1510, which includes a collection of one or more cores 142A-N and one or more shared cache units 1106; a system proxy unit 1110; one or more bus controller units 1116; one or more integrated memory controller units 1114; a collection of one or more coprocessors 1520, which may include integrated graphics logic, an image processor, an audio processor, and a video processor; a static random access memory (SRAM) unit 1530; a direct memory access (DMA) unit 1532; and a display unit 1540 for coupling to one or more external displays. In one embodiment, one or more coprocessors 1520 include a dedicated processor, such as, for example, a network or communication processor, a compression engine, a GPGPU, a high-throughput MIC processor, an embedded processor, or the like.

[0167] Embodiments of the mechanisms disclosed herein may be implemented in hardware, software, firmware, or a combination of such implementations. Embodiments of the present invention may be implemented as computer programs or program code executable on a programmable system, the programmable system including at least one processor, a storage system (including volatile and non-volatile memory and / or storage elements), at least one input device, and at least one output device.

[0168] Such as Figure 13 The program code 1330 shown can be applied to input instructions to perform the functions described herein and generate output information. The output information can be applied to one or more output devices in a well-known manner. For the purposes of this application, the processing system includes any system having a processor, such as, for example, a digital signal processor (DSP), a microcontroller, an application-specific integrated circuit (ASIC), or a microprocessor.

[0169] The program code can be implemented using a procedural or object-oriented high-level programming language to communicate with the processing system. The program code can also be implemented in assembly or machine language if needed. In fact, the mechanisms described in this document are not limited to any particular programming language. In any case, the language can be a compiled or interpreted language.

[0170] One or more aspects of at least one embodiment may be implemented by representative instructions stored on a machine-readable medium representing various logic within a processor, which, when read by a machine, cause the machine to manufacture the logic to perform the techniques described herein. Such a representation, referred to as an "IP core," may be stored on a tangible machine-readable medium and provided to various customer or production facilities for loading into the manufacturing machine that actually forms the logic or processor.

[0171] Such machine-readable storage media may include, but are not limited to, non-transient, tangible arrangements of articles made or formed by a machine or apparatus, including: storage media (e.g., hard disks), any other type of disk including floppy disks, optical disks, optical disc read-only memory (CD-ROM), rewritable optical discs (CD-RW), and magneto-optical disks; 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); phase-change memory (PCM); magnetic cards or optical cards; or any other type of media suitable for storing electronic instructions.

[0172] Accordingly, embodiments of the present invention also include non-transitory, tangible machine-readable media (containing instructions or design data, such as hardware description language (HDL)) that define the structures, circuits, devices, processors, and / or system features described herein. Such embodiments may also be referred to as program products.

[0173] Simulation (including binary conversion, code transformation, etc.)

[0174] In some cases, an instruction translator can be used to translate instructions from a source instruction set to a target instruction set. For example, an instruction translator can transform (e.g., using static binary translation, including dynamic binary translation with dynamic compilation), morphing, emulation, or otherwise convert instructions into one or more other instructions to be processed by the kernel. Instruction translators can be implemented in hardware, firmware, software, or a combination thereof. Instruction translators can be on-processor, off-processor, or partially on-processor and partially off-processor.

[0175] Figure 16 This is a block diagram illustrating the use of a software instruction converter to convert binary instructions in a source instruction set into binary instructions in a target instruction set, according to embodiments of the present invention. In the illustrated embodiment, the instruction converter is a software instruction converter; however, alternatively, the instruction converter may be implemented in software, firmware, hardware, or various combinations thereof. Figure 16 The diagram illustrates the ability to compile a program written in a high-level language 1602 using an x86 compiler 1604 to generate x86 binary code 1606 executable natively by a processor 1616 having at least one x86 instruction set core. A processor 1616 having at least one x86 instruction set core represents any processor capable of performing substantially the same function as an Intel processor having at least one x86 instruction set core, either by compatibility execution or otherwise processing (1) a substantial portion of the instruction set of an Intel x86 instruction set core or (2) an object code version of an application or other software directed to run on an Intel processor having at least one x86 instruction set core, in order to achieve substantially the same result as an Intel processor having at least one x86 instruction set core. The x86 compiler 1604 represents a compiler operable to generate x86 binary code 1606 (e.g., object code), which can be executed on a processor 1616 having at least one x86 instruction set core, with or without additional linking. Similarly, Figure 16The diagram illustrates the use of an alternative instruction set compiler 1608 to compile a program written in a high-level language 1602 to generate alternative instruction set binary code 1610. Code 1610 can be executed natively by a processor 1614 that does not have at least one x86 instruction set core (e.g., a processor with a core executing the MIPS instruction set of MIPS Technologies, Sunnyvale, California, and / or the ARM instruction set of ARM Holdings, Sunnyvale, California). An instruction converter 1612 is used to translate the x86 binary code 1606 into code that can be executed natively by the processor 1614 that does not have an x86 instruction set core. This translated code cannot be identical to the alternative instruction set binary code 1610 because an instruction converter capable of performing this operation would be difficult to manufacture; however, the translated code will implement general operations and consist of instructions from the alternative instruction set. Therefore, instruction converter 1612 represents software, firmware, hardware, or a combination thereof that allows a processor or other electronic device without an x86 instruction set processor or core to execute the x86 binary code 1606 through emulation, simulation, or any other process.

[0176] against Figure 1 , 2 The components, features, and details described in any of the figures in Figure 4 may also be applied. Figure 3 , 5 Any of the figures in 6, 7, and 8. Furthermore, the components, features, and details described for any device in the apparatus may also be applied to any method in the method, which in embodiments may be performed by and / or utilizing such a device. The processor may have different logic to perform... Figure 3 , 5 The different boxes for 7 and 8. Any processor described herein may include any computer system disclosed herein (e.g., Figure 12-15 In some embodiments, the computer system may include dynamic random access memory (DRAM). Alternatively, the computer system may include a type of volatile memory or flash memory that does not require refreshing. The instructions disclosed herein can be executed using any processor of the processor shown herein on any system of the systems shown herein, having any microarchitecture of the microarchitecture shown herein. The instructions disclosed herein may have any of the features of the instruction format described herein.

[0177] In this description and claims, the terms “coupled” and / or “connected”, along with their derivatives, have been used. These terms are not intended to be synonyms for each other. Rather, in embodiments, “connected” may be used to indicate that two or more elements are in direct physical and / or electrical contact with each other. “Coupled” may mean that two or more elements are in direct physical and / or electrical contact with each other. However, “coupled” may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other. For example, a running unit may be coupled to a register and / or decoding unit via one or more intermediate components. In the drawings, arrows are used to illustrate connections and couplings.

[0178] In this description and / or claims, the terms “logic,” “cell,” “module,” or “component” may be used. Each of these terms can be used to refer to hardware, firmware, software, or various combinations thereof. In exemplary embodiments, each of these terms may refer to an integrated circuit, an application-specific integrated circuit, analog circuitry, digital circuitry, a programmable logic device, a memory device including instructions, and such and various combinations thereof. In some embodiments, these may include at least some hardware (e.g., transistors, gates, other circuit components, etc.).

[0179] The term “and / or” may have been used. As used herein, the term “and / or” means one or the other or both (e.g., A and / or B means A or B or both A and B).

[0180] In the foregoing description, specific details have been set forth to provide a thorough understanding of the embodiments. However, other embodiments may be practiced without some of these specific details. The scope of the invention will not be determined by the specific examples provided above, but only by the claims below. In other instances, well-known circuits, structures, devices, and operations have been shown in block diagram form and / or without detail to avoid obscuring the understanding of this description. Where appropriate, reference numerals or terminating portions of reference numerals have been repeated in the drawings to indicate corresponding or similar elements that may optionally have similar or identical characteristics, unless otherwise specified or clearly apparent.

[0181] Certain operations may be performed by hardware components or implemented in machine-operable or circuit-operable instructions that can be used to cause and / or induce a machine, circuit, or hardware component (e.g., a processor, a portion of a processor, circuitry, etc.) programmed with those instructions to perform the operation. Operations may also be optionally performed by a combination of hardware and software. The processor, machine, circuit, or hardware may include specific or concrete circuitry or other logic (e.g., hardware potentially combined with firmware and / or software) operable to execute and / or process instructions and to store results in response to those instructions.

[0182] Some embodiments include an article of manufacture (e.g., a computer program product) that includes a machine-readable medium. The medium may include mechanisms for providing (e.g., storing) information in a machine-readable form. The machine-readable medium may provide (or have stored thereon) instructions or sequences of instructions that, if and / or when run by a machine, are operable to cause the machine to perform and / or cause the machine to perform one or more operations, methods, or techniques disclosed herein.

[0183] In some embodiments, a machine-readable medium may include a non-transitory machine-readable storage medium. For example, a non-transitory machine-readable storage medium may include a floppy disk, optical storage medium, optical disk, optical data storage device, CD-ROM, magnetic disk, magneto-optical disk, read-only memory (ROM), programmable ROM (PROM), erasable and programmable ROM (EPROM), electrically erasable and programmable ROM (EEPROM), random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), flash memory, phase-change memory, phase-change data storage material, non-volatile memory, non-volatile data storage device, non-transitory memory, non-transitory data storage device, etc. A non-transitory machine-readable storage medium does not consist of transiently propagated signals. In some embodiments, the storage medium may include a tangible medium comprising a solid substance.

[0184] Examples of suitable machines include, but are not limited to, general-purpose processors, special-purpose processors, digital logic circuits, integrated circuits, and so on. Other examples of suitable machines include computer systems or other electronic devices that include processors, digital logic circuits, or integrated circuits. Examples of such computer systems or electronic devices include, but are not limited to, desktop computers, laptop computers, notebook computers, tablet computers, netbooks, smartphones, cellular phones, servers, network devices (such as routers and switches), mobile internet devices (MIDs), media players, smart TVs, all-in-one desktops (nettops), set-top boxes, and video game controllers.

[0185] The use of terms such as "an embodiment," "an embodiment," "one or more embodiments," and "some embodiments" throughout this specification indicates that specific features may be included in the practice of the invention, but are not necessarily required. Similarly, in the description, various features are sometimes grouped together in a single embodiment, drawing, or description thereof for the purpose of simplifying this disclosure and aiding in understanding various aspects of the invention. However, this approach to disclosure is not to be construed as reflecting an intention to claim more features than are clearly stated in each claim. Rather, as reflected in the following claims, aspects of the invention lie in fewer than all features of a single disclosed embodiment. Therefore, the claims following the detailed description are thus clearly incorporated into that detailed description, wherein each claim stands independently as a separate embodiment of the invention.

[0186] Example Implementation

[0187] The following examples relate to other embodiments. Specific details in the examples may be used anywhere in one or more embodiments.

[0188] Example 1 is a processor that includes a decoding unit for decoding a user-level instruction to pause a thread, indicating a first alternative state. The processor also includes an execution unit coupled to the decoding unit. The execution unit is operable to execute instructions at a user privilege level. In response to the instructions, the execution unit will: (1) pause the execution of a user-level thread having received instructions from the user-level thread; (2) transition the logical processor on which the user-level thread is currently running to the indicated first alternative state; and (3) while the logical processor is in the indicated first alternative state, resume the execution of the user-level thread with a delay less than half the delay at which the execution of the thread can be resumed when the logical processor is in a stopped processor power state.

[0189] Example 2 includes the processor described in Example 1, wherein the decoding unit is configured to decode an instruction having a field for selecting a first alternative state as any one of a plurality of different possible alternative states.

[0190] Example 3 includes the processor described in Example 2, wherein the plurality of different possible alternative states includes a second alternative state. Alternatively, the second alternative state would allow resumption of execution of user-level threads with a delay no greater than the delay when the logical processor is in a stopped processor power state.

[0191] Example 4 includes the processor described in any one of Examples 1 to 3, and further includes a storage location for storing a timeout value imposed by the monitoring system software. Optionally, in response to the instruction, the execution unit will: (1) determine that the timeout value imposed by the monitoring system software has expired; and (2) also optionally resume execution of the user-level thread in response to determining that the timeout value imposed by the monitoring system software has expired.

[0192] Example 5 includes the processor described in any one of Examples 1 to 4, and further includes an architecturally visible storage location. In response to the instruction, the execution unit stores in the architecturally visible storage location an instruction to resume execution of a user-level thread due to the expiration of a timeout value imposed by the monitoring system software.

[0193] Example 6 includes the processor described in Example 5, wherein, in response to the instruction, the execution unit stores the indication by modifying the architecture flag in a register used to store multiple flags.

[0194] Example 7 includes the processor described in any one of Examples 1 to 6, wherein the decoding unit is configured to decode an instruction indicating a user-level timeout value. Alternatively, in response to the instruction, the execution unit will: (1) determine that the user-level timeout value has expired; and (2) also optionally resume execution of the user-level thread in response to determining that the user-level timeout value has expired.

[0195] Example 8 includes the processor of any one of Examples 1 to 7, wherein, when the logical processor is in the indicated first alternative state, in response to the instruction, the execution unit will resume the execution of the user-level thread with a delay less than one-fifth of the delay when the logical processor is in a stopped processor power state.

[0196] Example 9 includes the processor described in any one of Examples 1 to 8, wherein, when the logic processor is in the indicated first alternative state, in response to the instruction, the execution unit will resume the execution of the user-level thread by a delay of less than five hundred clock cycles.

[0197] Example 10 includes the processor described in any one of Examples 1 to 9, wherein, in response to the instruction, the execution unit resumes the execution of the user-level thread without exiting the user privilege level.

[0198] Example 11 is a method in a processor, the method including receiving a user-level pause thread instruction from a user-level thread, the instruction indicating a first alternative state. The method further includes executing the instruction at a user privilege level, including: (1) pausing the execution of the user-level thread; (2) transitioning a logical processor on which the user-level thread was previously running to the indicated first alternative state; and (3) while the logical processor is in the indicated first alternative state, resuming the execution of the user-level thread with a delay less than half the delay required to resume execution when the logical processor is in a stopped processor power state.

[0199] Example 12 includes the method of Example 11, wherein receiving includes receiving an instruction having a field for selecting a first alternative state as any one of a plurality of different possible alternative states.

[0200] Example 13 includes the method of any one of Examples 11 to 12, wherein the plurality of different possible alternative states includes a second alternative state. Alternatively, the second alternative state allows for the resumption of execution of user-level threads with a delay no greater than the delay when the logical processor is in a stopped processor power state.

[0201] Example 14 includes the method of any one of Examples 11 to 13, further comprising: (1) determining that a timeout value imposed by the monitoring system software has expired; and (2) optionally resuming the execution of a user-level thread in response to determining that a timeout value imposed by the monitoring system software has expired.

[0202] Example 15 includes the method described in Example 14, further including storing in a storage location visible on the processor architecture an instruction that execution of a user-level thread has resumed due to the expiration of a timeout value imposed by the monitoring system software.

[0203] Example 16 includes the method of Example 15, wherein storing the indication includes modifying the architecture flags in a register used to store a plurality of architecture flags, and also includes a timeout value imposed by supervisory system software from a control register of the processor.

[0204] Example 17 includes the method of any one of Examples 11 to 16, wherein receiving includes receiving an instruction indicating a user-level timeout value, and optionally, the method further includes: (1) determining that the user-level timeout value has expired; and (2) optionally resuming the execution of a user-level thread in response to determining that the user-level timeout value has expired.

[0205] Example 18 includes the method of any one of Examples 11 to 17, wherein when the logical processor is in the indicated first alternative state, the resumption of execution of the user-level thread is achieved with a delay less than one-fifth of the delay when the logical processor is in a stopped processor power state.

[0206] Example 19 includes the method of any one of Examples 11 to 19, wherein execution of a user-level thread is resumed without exiting the user privilege level.

[0207] Example 20 is a system for processing instructions, the system including an interconnect and a processor coupled to the interconnect. The processor is configured to receive a user-level pause thread instruction. The instruction, for indication, indicates a first alternative state. The processor is operable to execute the instruction at a user privilege level and, in response to the instruction, will: (1) pause the execution of the corresponding user-level thread; (2) transition one of the following—a single-threaded core, hardware thread, thread unit, thread slot, and logical processor on which the user-level thread is running, having a dedicated context and a dedicated program counter—to the indicated first alternative state; and (3) when said one is in the indicated first alternative state, resume the execution of the user-level thread with a delay less than half the delay at which the thread could be resumed when said one is in a stopped processor power state. The system may also optionally include dynamic random access memory (DRAM) coupled to the interconnect.

[0208] Example 21 includes the system described in Example 20, wherein the instructions will have a field for selecting a first alternative state as any one of a plurality of different possible alternative states.

[0209] Example 22 is an article of manufacture including a non-transitory machine-readable storage medium. The non-transitory machine-readable storage medium stores a user-level instruction to suspend a thread. The instruction is operable to indicate a first alternative state. The instruction is operable to execute at a user privilege level. If executed by a machine, the instruction causes the machine to perform operations including: (1) suspending the execution of a user-level thread corresponding to the instruction; (2) transitioning one of a single-threaded core, hardware thread, thread unit, thread slot, and logical processor on which a user-level thread is running to the indicated first alternative state; and (3) resuming the execution of the user-level thread from the logical processor in the indicated first alternative state with a delay less than half the delay of resuming the execution of a thread when the logical processor is in a stopped processor power state.

[0210] Example 23 includes the article of manufacture described in Example 22, wherein the instructions have a field for selecting a first alternative state as any one of a plurality of different possible alternative states.

[0211] Example 24 includes the article of any one of Examples 22 to 23, wherein the instructions, if executed by a machine, would further cause the machine to perform operations including: (1) determining that a timeout value imposed by the monitoring system software has expired; and (2) optionally resuming the execution of a user-level thread in response to the determination that the timeout value imposed by the monitoring system software has expired.

[0212] Example 25 includes the article of any one of Examples 22 to 24, wherein the instructions, if executed by a machine, would further cause the machine to perform operations including: (1) determining that a user-level timeout value has expired; and (2) optionally resuming the execution of a user-level thread in response to determining that a user-level timeout value has expired.

[0213] Example 26 includes the processor described in any one of Examples 1 to 10, further comprising an optional branch prediction unit for predicting branches, and an optional instruction prefetch unit coupled to the branch prediction unit, the instruction prefetch unit being used to prefetch instructions including user-level paused thread instructions. The processor may optionally also include an optional Level 1 (L1) instruction cache coupled to the instruction prefetch unit, an L1 instruction cache for storing instructions, an optional L1 data cache for storing data, and an optional Level 2 (L2) cache for storing data and instructions. The processor may optionally also include an instruction fetch unit coupled to a decoding unit, the L1 instruction cache, and the L2 cache to fetch user-level paused thread instructions from one of the L1 instruction cache and the L2 cache in some cases, and to provide user-level paused thread instructions to the decoding unit. The processor may optionally also include a register renaming unit for renaming registers, an optional scheduler for scheduling one or more operations that have been decoded from user-level paused thread instructions for execution, and an optional commit unit for committing the execution results of user-level paused thread instructions.

[0214] Example 27 includes a system-on-a-chip (SoC) comprising at least one interconnect, a processor coupled to any one of Examples 1 to 10, an optional graphics processing unit (GPU) coupled to the at least one interconnect, an optional digital signal processor (DSP) coupled to the at least one interconnect, an optional display controller coupled to the at least one interconnect, an optional memory controller coupled to the at least one interconnect, an optional wireless modem coupled to the at least one interconnect, an optional image signal processor coupled to the at least one interconnect, an optional Universal Serial Bus (USB) 3.0 compatible controller coupled to the at least one interconnect, an optional Bluetooth 4.1 compatible controller coupled to the at least one interconnect, and an optional wireless transceiver controller coupled to the at least one interconnect.

[0215] Example 28 is a processor or other device operable to perform the method of any one of Examples 11 to 19.

[0216] Example 29 is a processor or other device that includes components for performing the method of any one of Examples 11 to 19.

[0217] Example 30 is a processor or other device that includes any combination of modules and / or units and / or logic and / or circuits and / or components operable to perform the method of any one of Examples 11 to 19.

[0218] Example 31 is an optional non-transitory and / or tangible machine-readable medium that optionally stores or otherwise provides instructions including a first instruction that, if and / or when executed by a processor, computer system, electronic device, or other machine, is operable to cause the machine to perform any one of Examples 11 to 19.

[0219] Example 32 is a processor or other device that is essentially as described herein.

[0220] Example 33 is a processor or other device operable to perform essentially any of the methods described herein.

[0221] Example 34 is a processor or other device operable to execute virtually any user-level thread-pause instruction as described herein.

[0222] Example 35 is a computer system or other electronic device including a processor having a decoding unit operable to decode instructions of a first instruction set. The processor also has one or more execution units. The electronic device further includes a storage device coupled to the processor. The storage device is operable to store a first instruction, which may be substantially any instruction disclosed herein, and the first instruction will belong to a second, different instruction set. The storage device is also operable to store instructions for translating the first instruction into one or more instructions of the first instruction set. The one or more instructions of the first instruction set, when executed by the processor, are operable to cause the processor to have the same effect as if the first instruction were executed directly.

Claims

1. A processor, comprising: A decoding unit for decoding a user-level thread pause instruction for a user-level thread, wherein the user-level thread pause instruction is used to indicate a first alternative state; as well as An execution unit coupled to the decoding unit is configured to perform, with user-level privileges, an operation corresponding to the user-level pause thread instruction when the user-level pause thread instruction is included within a transaction memory transaction, without aborting the transaction memory transaction. The operation includes: Pause the execution of the user-level thread; Transition the logical processor corresponding to the user-level thread to the indicated first alternative state; and In response to a thread resumption condition, the execution of the user-level thread is resumed from the first alternative state with a delay of less than 500 clock cycles.

2. The processor of claim 1, wherein the latency is less than two hundred clock cycles.

3. The processor of claim 1, wherein the user-level pause thread instruction is used to indicate the first alternative state as one of a plurality of possible alternative states.

4. The processor of claim 3, wherein the plurality of possible alternative states includes a second alternative state, from which execution of the user-level thread is resumed with a delay less than that of the first alternative state.

5. The processor of claim 4, wherein the delay of the first alternative state and the delay of the second alternative state are less than the delay of the stop state.

6. The processor of claim 1, wherein the user-level pause thread instruction has a source operand for specifying a user-level timeout value.

7. The processor of claim 1 further includes a control register for storing a timeout value imposed by the monitoring system software.

8. The processor of claim 7, wherein the execution unit is configured to: Determine whether the timeout value applied by the monitoring system software has expired; and When the timeout value applied by the monitoring system software has expired, an indication that the timeout value applied by the monitoring system software has expired is stored.

9. The processor of claim 1, wherein the user-level pause thread instruction has a source operand for specifying a user-level timeout value, and further includes a control register for storing a timeout value imposed by monitoring system software.

10. A method in a processor, comprising: Receive a user-level pause thread instruction from a user-level thread within a transaction in the transaction storage, the user-level pause thread instruction indicating a first alternative state; Performing an operation corresponding to the user-level pause thread instruction with user-level privileges, without aborting the transaction memory transaction, the operation includes: Pause the execution of the user-level thread; Transition the logical processor corresponding to the user-level thread to the indicated first alternative state; Detect thread recovery conditions; and Upon detecting the thread recovery condition, the execution of the user-level thread is resumed from the first alternative state with a delay of less than 500 clock cycles.

11. The method of claim 10, wherein the user-level thread is recovered with a delay of less than two hundred clock cycles.

12. The method of claim 10, wherein the user-level pause thread instruction indicates the first alternative state as one of a plurality of possible alternative states.

13. The method of claim 12, wherein the plurality of possible alternative states includes a second alternative state from which execution of the user-level thread can be resumed with a delay less than that of the first alternative state.

14. The method of claim 10, wherein the user-level pause thread instruction has a source operand with a specified user-level timeout value.

15. The method of claim 10, further comprising a control register storing a timeout value imposed by the monitoring system software.

16. The method of claim 15, further comprising: The timeout value applied by the monitoring system software is determined to have expired as a condition for thread recovery; as well as The system stores an indication that the timeout value applied by the monitoring system software has expired.

17. A system comprising: interconnection; Dynamic random access memory (DRAM) coupled to the interconnect; A processor coupled to the interconnect, the processor comprising: A decoding unit for decoding user-level thread pause instructions for user-level threads, wherein the user-level thread pause instructions are used to indicate a first alternative state; and An execution unit coupled to the decoding unit is configured to perform, with user-level privileges, an operation corresponding to the user-level pause thread instruction when the user-level pause thread instruction is included within a transaction memory transaction, without aborting the transaction memory transaction. The operation includes: Pause the execution of the user-level thread; Transition the logical processor corresponding to the user-level thread to the indicated first alternative state; and In response to a thread resumption condition, the execution of the user-level thread is resumed from the first alternative state with a delay of less than 500 clock cycles.

18. The system of claim 17, wherein the user-level pause thread instruction has a source operand for specifying a user-level timeout value, and further includes a control register for storing a timeout value imposed by the monitoring system software.

19. The system of claim 18, wherein the execution unit is configured to: Determine whether the timeout value applied by the monitoring system software has expired; and When the timeout value applied by the monitoring system software has expired, an indication that the timeout value applied by the monitoring system software has expired is stored.

20. An apparatus comprising: A component for receiving a user-level pause thread instruction from a user-level thread within a transactional memory transaction, the user-level pause thread instruction indicating a first alternative state; A component for executing, with user-level privileges, an operation corresponding to a user-level pause thread instruction without aborting the transaction memory transaction, the operation including: Pause the execution of the user-level thread; Transition the logical processor corresponding to the user-level thread to the indicated first alternative state; Detect thread recovery conditions; and Upon detecting the thread recovery condition, the execution of the user-level thread is resumed from the first alternative state with a delay of less than 500 clock cycles.

21. The device of claim 20, wherein the user-level thread is recovered with a delay of less than two hundred clock cycles.

22. The device of claim 20, wherein the user-level pause thread instruction indicates the first alternative state as one of a plurality of possible alternative states.

23. The device of claim 22, wherein the plurality of possible alternative states includes a second alternative state from which execution of the user-level thread can be resumed with a delay less than that of the first alternative state.

24. The device of claim 20, wherein the user-level pause thread instruction has a source operand with a specified user-level timeout value.

25. The device of claim 20, further comprising a control register storing a timeout value applied by the monitoring system software.

26. The apparatus of claim 25, further comprising: A component used to determine that the timeout value applied by the monitoring system software has expired as a condition for thread recovery; as well as A component for storing indications that the timeout value applied by the monitoring system software has expired.

27. A computer-readable medium having instructions stored thereon, which, when executed, cause a computing device to perform the method according to any one of claims 10-16.

Images