Abstract: Method, apparatus and system embodiments to schedule user-level OS-independent “shreds” without intervention of an operating system. For at least one embodiment, the shred is scheduled for execution by a scheduler routine rather than the operating system. The scheduler routine resides in user space and may be part of a runtime library. The library may also include monitoring logic that monitors execution of a shredded program and provides scheduling hints, based on shred dependence information, to the scheduler. In addition, the scheduler may further optimize shred scheduling by taking into account information about a system's configuration of thread execution hardware. Other embodiments are also described and claimed.

Abstract: In an embodiment, a method is provided. The method includes managing user-level threads on a first instruction sequencer in response to executing user-level instructions on a second instruction sequencer that is under control of an application level program. A first user-level thread is run on the second instruction sequencer and contains one or more user level instructions. A first user level instruction has at least 1) a field that makes reference to one or more instruction sequencers or 2) implicitly references with a pointer to code that specifically addresses one or more instruction sequencers when the code is executed.

Abstract: A processor may include an address monitor table and an atomic update table to support speculative threading. The processor may also include one or more registers to maintain state associated with execution of speculative threads. The processor may support one or more of the following primitives: an instruction to write to a register of the state, an instruction to trigger the committing of buffered memory updates, an instruction to read the a status register of the state, and/or an instruction to clear one of the state bits associated with trap/exception/interrupt handling. Other embodiments are also described and claimed.

Abstract: Method, apparatus, and system for a programmable event driven yield mechanism that may activate other threads. The yield mechanism may allow triggering of a service thread that may execute currently with a main thread upon occurrence of an architecturally-defined condition. The service thread may be activated, in response to the condition, with limited intervention of an operating system. In one embodiment, an apparatus includes execution resources to execute a plurality of instructions and a monitor to detect an architecturally-defined condition. The apparatus may include an event handler to handle a yield event generated when the architecturally-defined condition has been detected. An architectural mechanism, including processor instructions and channel registers, may be utilized to allow user-level code to enable the yield event mechanism. Other embodiments are also described and claimed.

Abstract: A technique to monitor software thread performance and update software that issues or uses the thread(s) to reduce performance-inhibiting events. At least one embodiment of the invention uses hardware and/or software timers or counters to monitor various events associated with executing user-level threads and report these events back to a user-level software program, which can use the information to avoid or at least reduce performance-inhibiting events associated with the user-level threads.

Abstract: Operating system services are transparently triggered for thread execution resources (“sequencers”) that are sequestered from view of the operating system. A “surrogate” thread that is managed by, and visible to, the operating system is utilized to acquire OS services on behalf of a sequestered sequencer. Multi-shred contention for shred-specific resources may thus be alleviated. Other embodiments are also described and claimed.

Abstract: Disclosed are embodiments of a system, methods and mechanism for management and translation of mapping between logical sequencer addresses and physical or logical sequencers in a multi-sequencer multithreading system. A mapping manager may manage assignment and mapping of logical sequencer addresses or pages to actual sequencers or frames of the system. Rationing logic associated with the mapping manager may take into account sequencer attributes when such mapping is performed Relocation logic associated with the mapping manager may manage spill and fill of context information to/from a backing store when re-mapping actual sequencers. Sequencers may be allocated singly, or may be allocated as part of partitioned blocks. The mapping manager may also include translation logic that provides an identifier for the mapped sequencer each time a logical sequencer address is used in a user program. Other embodiments are also described and claimed.

Abstract: Method, apparatus and system embodiments to schedule OS-independent “shreds” without intervention of an operating system. For at least one embodiment, the shred is scheduled for execution by a scheduler routine rather than the operating system. A scheduler routine may run on each enabled sequencer. The schedulers may retrieve shred descriptors from a queue system. The sequencer associated with the scheduler may then execute the shred described by the descriptor. Other embodiments are also described and claimed.

Abstract: Method, apparatus and system embodiments to provide user-level creation, control and synchronization of OS-invisible “shreds” of execution via an abstraction layer for a system that includes one or more sequencers that are sequestered from operating system control. For at least one embodiment, the abstraction layer provides sequestration logic, proxy execution logic, transition detection and shred suspension logic, and sequencer arithmetic logic. Other embodiments are also described and claimed.

Abstract: A platform and method for secure handling of events in an isolated execution environment. A processor executing in isolated execution “IsoX” mode may leak data when an event occurs as a result of the event being handled in a traditional manner based on the exception vector. By defining a class of events to be handled in IsoX mode, and switching between a normal memory map and an IsoX memory map dynamically in response to receipt of an event of the class, data security may be maintained in the face of such events.

Abstract: Methods and systems are provided to selectively log branch trace store data associated with the execution of an application. A privilege level is received, which identifies an execution mode for a processor for which branch trace store data is to be logged to a buffer. The privilege level is used to set one or more privilege flags that permit selective branch trace store data to be logged in the buffer when the application is executed. In one embodiment, the privilege level represents a user application mode, a supervisory application mode, or a mode representing both a user application mode and a supervisory application mode.

Abstract: In one embodiment, the present invention includes a method to establish a secure pre-boot environment in a computer system; and perform at least one secure operation in the secure environment. In one embodiment, the secure operation may be storage of a secret in the secure pre-boot environment.

Abstract: The present invention is a method and apparatus for switching first and second tasks in an operating system. The first and second tasks each have first and second traditional states and first and second extended states, in a processing unit. The method comprises: (a) saving the first traditional and extended states from the processing unit to a buffer; (b) updating the buffer by replacing the first extended state by the second extended state; and (c) restoring the first traditional state and the second extended state in the processing unit from the updated buffer.