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: 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: 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: 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 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: 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: 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: 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: Processor extensions and software verification to support type-safe language environments running with untrusted code. Code and data spaces are partitioned into trusted and untrusted regions. Type-safe code is loaded into the trusted region of the code space, while non-type-safe code is loaded into the untrusted region of the code space. The trusted region of the data space is allocated to the type-safe code. The untrusted region of the data space is allocated to the non-type-safe code. Hardware-based truth tables are employed for defining allowable and disallowable code sequences and memory access operations. For code sequences, allowable operations are based on the location (i.e., region) of a code sequence including a current instruction and a prior instruction. For memory access, the location of the requesting instruction and data requested are considered. Disallowed code sequence or memory access operations cause the processor to generate a safe access protection trap.