|Publication number||US5684993 A|
|Application number||US 08/632,750|
|Publication date||Nov 4, 1997|
|Filing date||Apr 16, 1996|
|Priority date||Jan 4, 1993|
|Publication number||08632750, 632750, US 5684993 A, US 5684993A, US-A-5684993, US5684993 A, US5684993A|
|Original Assignee||Microsoft Corporation|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (8), Non-Patent Citations (8), Referenced by (41), Classifications (13), Legal Events (4)|
|External Links: USPTO, USPTO Assignment, Espacenet|
This application is a continuation of U.S. patent application Ser. No. 08/000,365, filed Jan. 4, 1993, now abandoned.
This invention relates generally to data processing systems and, more particularly, to storage of CPU-specific data in multi-processor systems.
The 80386 microprocessor and compatible processors, including the 80486 and Pentium, sold by Intel Corporation of Cupertino, Calif., may operate in one of at least three processor modes: real mode, protected mode or virtual-86 mode. Real mode is provided as a carry over from earlier INTEL processors and allows code written for real mode of earlier processors to be executed on the 80386. Protected mode provides mechanisms that protect data from unauthorized access, support multi-tasking and perform sophisticated memory management. Virtual-86 mode allows code that was written for an 8086 microprocessor (a predecessor to the 80386) to be executed in protected mode on the 80386. The code is run in a virtualized manner in an environment that appears to the code as an 8086 microprocessor.
The addressing scheme of the microprocessor differs with processor mode.
In protected mode, the 80386 microprocessor uses an addressing architecture, like that shown in FIG. 1. In protected mode, facilities for both segmentation and paging are used. Programs that are run on the 80386 microprocessor in protected mode use virtual addresses. Each virtual address includes a 16-bit selector 101 and a 32-bit offset 102. The selector 101 identifies a segment (i.e., a contiguous block of memory) in the virtual address s The offset 102 specifies an offset in the identified segment from the base address of the segment. The virtual address 100 is mapped by a segmentation system 103 into a 32-bit linear address 104. The resulting address 104 is known as a "linear" address because the address lies within a one dimensional or "linear" address space. In contrast, the virtual address space is a two-dimensional address space. The selector 101 of a virtual address specifies a first dimension (i.e., a segment), and the offset 102 of the virtual address specifies a second dimension. The linear address 104 is passed to a paging system 105, where the linear address is translated into a 32-bit physical address 106.
FIG. 2 shows the segmentation system 103 in more detail. As was mentioned above, the segmentation system 103 maps the virtual address 100 into a linear address 104. The segmentation system 103 includes at least one segment descriptor table 107. The segment descriptor table 107 is a table held in memory that includes entries containing information about segments of virtual memory. The 16-bit selector 101 of the virtual address 100 is used as an index into the segment descriptor table 107 to retrieve an entry 111. The specified entry 111 includes three fields: an attributes field 108, a limit field 109 and a base address field 110. The base address field 110 provides the base address of the segment associated with the entry. The limit field 109 specifies the length of the segment, and the attributes field 108 specifies the access rights of the segment (i.e., read, write or execute). The base address 110 is added to the 32-bit offset field 102 of the virtual address 100 to obtain the linear address 104.
Two types of segment descriptor tables are employed in protected mode on the 80386 microprocessor. First, a global descriptor table (GDT) is employed to hold descriptors pointing to segments of memory in the global address space that are accessible by all tasks run on the microprocessor. Second, a local descriptor table (LDT) is employed to point to memory segments that are local to a task. All other tasks may not access these local segments of memory.
The 80386 microprocessor provides segment registers for holding segment selectors, so that addressing may be performed by referencing the segment registers. In particular, virtual addresses are specified by a segment register and an offset. As shown in FIG. 3, the segment registers include a code segment register (CS), a stack segment register (SS), a main data segment register (DS) and three additional segment registers (ES, FS and GS).
The use of the segment registers CS, SS, DS, ES, FS and GS enhances system efficiency by eliminating the need to access a segment descriptor table 107 (FIG. 2) every time that address translation is performed. The 80386 provides a cache register for each segment register CS, SS, DS, ES, FS and GS (see FIG. 3). Each cache register contains the contents of the segment descriptor table entry that is indexed by the segment selector in the corresponding segment register. When a segment register is loaded with a segment selector, a CPU retrieves an entry from the segment descriptor table 107 (FIG. 2) using the segment selector as the index. The retrieved base address, limit and attributes fields of the retrieved entry are stored in the cache registers (FIG. 3). Thus, subsequent accesses to the segment need not retrieve the entry from the segment descriptor table 107 (FIG. 2); rather the contents of the entry may be obtained directly from the cache registers (FIG. 3).
FIG. 4 depicts the paging system 105 of FIG. 1 in more detail. The paging system 105 includes a CR3 control register 126, at least one page directory 118 and at least one page table 122. The paging system 105 is responsible for converting the linear address 104 into the physical address 106. The linear address 104 includes three fields: a directory index field 112 (Dir.), a page field 114 (Page) and an offset field 116 (Offset). The directory index field 112 is a 10-bit field that serves as an index into the page directory 118. The page field 114 is a 10-bit field that acts as an index into the page table 122, and the offset field 116 specifies an offset within a page frame.
The paging system 105 typically includes multiple page directories. The page directory 118 to be used in converting the linear address 104 into the physical address 106 is specified by the CR3 control register 126. The CR3 control register 126 is one of a number of control registers that are provided within the 80386 microprocessor. The directory index field 112 of the linear address 104 is used to specify an entry 120 in the page directory 118, which holds a pointer to the page table 122. Typically, the paging system 105 includes a number of page tables, and the entry 120 in the page directory 118 specifies which of the page tables is to be used.
The page field 114 of the linear address 104 is then used as an index to select an entry 124 in the page table 122. Entry 124 specifies the base address of a page frame 128 in physical memory. The base address of the page frame 128 is combined with the 12-bit offset field 116 to generate the physical address 106. The page frame base address forms the most significant 20 bits of the physical address 106, whereas the offset field 116 forms the least significant 12 bits of the physical address 106.
The 80386 microprocessor is designed to support multi-tasking. Multi-tasking refers to when multiple tasks are run concurrently on a CPU under the control of an operating system. Typically, each task is given a time slice in which it is allowed to execute on the CPU before the next task is run on the CPU. The net result is that there are multiple tasks in various stages of execution which cooperatively share the CPU under the control of the operating system.
Many data processing systems include more than one CPU. These systems are generally referred to as "multi-processor systems." In general, the CPUs of a multi-processor system execute independently. As such, the CPUs are often used to run separate tasks in parallel.
An operating system run on a multi-processor system maintains CPU-specific data for each CPU. The CPU-specific data is data that the operating system must maintain on a per-CPU basis. CPU-specific data includes data such as the identity of a task that is currently executing on a CPU. The CPU-specific data must be accessible to the operating system at any time and must be cheaply accessible, as it is used frequently.
It is, therefore, an object of the present invention to provide an approach for storing CPU-specific data in a multi-tasking, multi-threading operating system that is run on a multi-processor system.
It is a further object of the present invention to allow access to CPU-specific data in a very fast manner with minimal memory use.
It is another object of the present invention to allow access to CPU-specific data in a manner that allows use of a single system image (i.e., use of common virtual addresses on all CPUs in a system).
It is yet another object of the present invention to segregate CPU-specific data from shared task information in a multi-tasking, multi-threading operating system that is run on a multi-processor system.
The foregoing and other objects are realized by the present invention. In accordance with one aspect of the present invention, a method of segregating CPU-specific data from shared task information is practiced in a multi-processor system. The multi-processor system includes a memory and at least two CPUs which execute different threads of computation of the task. In accordance with this method, the shared task information is placed in memory locations of the memory that are accessible by both of the CPUs. The CPU-specific data is placed in memory locations that are directly addressable only by the associated CPU. In other words, these memory locations are only visible to the CPU whose CPU-specific data is stored in the memory locations.
In accordance with another aspect of the present invention, a method is practiced in a multi-processor system having a memory and multiple CPUs. Multiple threads of a task are executed across the multiple CPUs. In accordance with the method, global descriptor tables are provided in memory for address translation. A unique one of the global descriptor tables is associated with each CPU. Each global descriptor table includes indexed entries that point to memory segments that are globally accessible to threads of computation executed on the associated CPU. Like indexed entries in the respective global descriptor tables are filled with identical entries. However, at least one like indexed entry in each global descriptor table is filled with a segment selector that points to a segment in the memory holding CPU-specific data. Thus, although the CPU-specific data is held in the global memory space that is accessible by all of the CPUs, the CPU-specific data is only visible to the associated CPU.
In accordance with still another aspect of the present invention, a multi-processor system has at least two CPUs for executing separate threads of computation of a task. The multi-processor system also has a memory, that is logically divided into memory segments. The multi-processor system runs a multi-threading operating system on the CPUs to control the processors. A global descriptor table is held in memory for each CPU. The global descriptor tables are used by the operating system in address translation. Each global descriptor table holds entries that point to memory segments that are accessible to all tasks. Furthermore, each global descriptor table includes at least one entry that points to a memory segment that holds CPU-specific information that is directly addressable only by the associated CPU.
In accordance with an additional aspect of the present invention, a method of accessing CPU-specific data is practiced in a data processing system. The data processing system includes multiple CPUs and a memory that is logically partitioned into segments. In accordance with this method, a descriptor table for use in address translation is stored in memory for each CPU. Each descriptor table includes like indexed entries that include descriptors. The descriptors point to segments of memory that are accessible to threads executed by the CPUs. Each descriptor table also includes at least one entry having a descriptor that points to a segment holding CPU-specific data for the associated CPU. The entry in the descriptor table that points to the CPU-specific data is accessed to obtain a descriptor for the segment holding the CPU-specific data. The descriptor is then used to obtain an address for the CPU-specific data, and subsequently, the address is used to access the CPU-specific data.
The data processing system in which the method is practiced may include a register for holding an index into the descriptor table. When such a register is employed in the data processing system, the method may include the additional step of using the register to obtain an index of the entry in the descriptor table which holds CPU-specific data. A descriptor table may be a global descriptor table, and the register may be a segment register.
In accordance with still yet another aspect of the present invention, a method is practiced in the data processing system having a memory that is logically partitioned into segments and multiple CPUs executing separate threads of a task. In accordance with this method, a page directory is provided in memory, and the page directory is local to the task and includes entries that hold a pointer to a page table. A global descriptor table is provided in memory for each CPU. The global descriptor table is used in translating a virtual address, having a selector and an offset, into a linear address. Each global descriptor table holds like entries at like indexes and holds at least one entry at a like index that includes a descriptor for a segment of memory holding CPU-specific data.
A selector in a virtual address is used as an index to access the entry in a global descriptor table of a CPU which holds the descriptor for the segment of memory holding CPU-specific data. The descriptor includes a base address of the segment of memory that holds the CPU-specific data. An offset in the virtual address is added to the base address of the segment of memory holding the CPU-specific data to obtain a linear address. Bits in the linear address are used as an index into the page directory to obtain a pointer to a page table that is to be used in address translation. The bits in the linear address are used as an index into the page table. These bits specify an entry holding a page frame address. The page frame address is combined with offset bits in the linear address to obtain a physical address. The physical address is used to access a memory location in the segment of memory holding the CPU-specific data.
FIG. 1 is a block diagram of the addressing architecture of a conventional 80386 microprocessor.
FIG. 2 is a block diagram illustrating the segmentation system 103 of FIG. 1 in more detail.
FIG. 3 is a block diagram of the segment registers and segment descriptor cache registers of a conventional 80386 microprocessor.
FIG. 4 is a more detailed block diagram of the paging system 105 of FIG. 1.
FIG. 5a is a block diagram illustrating how CPU-specific data may be stored in physical memory for a multi-tasking operating system, which differs from the preferred embodiment of the present invention described herein in that it does not support multi-threading.
FIG. 5b is a block diagram illustrating the problem of adopting the approach shown in FIG. 5a, when a single image of a multi-threading operating system is run on a multi-processor system.
FIG. 6 is a block diagram of an illustrative multi-processor system on which a preferred embodiment of the present invention may be implemented.
FIG. 7 is a block diagram illustrating segregation of CPU-specific data in the preferred embodiment of the present invention described herein.
The present invention will now be described with reference to a preferred embodiment that provides separate storage of CPU-specific data by multiple CPUs of a multi-processor system in an operating system that supports multi-tasking and multi-threading. CPU-specific data refers to data, like that described above, and additionally refers, in the preferred embodiment described herein, to information such as the identity of the thread currently executing on a CPU. The preferred embodiment of the present invention described herein uses GDTs to enable each CPU to store CPU-specific data in a multi-threading environment without requiring additional hardware and without substantially increasing memory requirements.
FIG. 5a provides an example of how CPU-specific data may be stored in an operating system that supports multi-tasking but not multi-threading. This approach should not be confused with the preferred embodiment of the present invention described herein. Rather, this approach is shown to illustrate the limitations posed by such an approach. The solution set forth in FIG. 5a stores CPU-specific data for a CPU in memory that is local to the task being run on the CPU. The operating system is run on a multi-processor system having two CPUs, CPU0 and CPU1, that are executing distinct tasks. It should be noted that the phrase "paging tables" is used herein to refer to the combination of a page table and a page directory, as shown in FIG. 4, for specifying a page frame in physical memory. Paging tables are allocated on a per-task basis; hence, the task run on CPU0 and the task run on CPU1 use different sets of paging tables 130 and 132. The CR3 registers 140 and 142 of CPU0 and CPU1 point to their respective sets of paging tables 130 and 132 (i.e., to the page directories in the paging tables). The CR3 register 140 of CPU0 points to paging tables 130, and the CR3 register 142 of CPU1 points to paging tables 132. The CPU-specific data of CPU0 and CPU1 are both stored at linear address "3G" (where G indicates gigabytes). This same linear address, however, is mapped to different page frames in physical memory by the respective paging tables 130 and 132. Thus, the CPU-specific data for CPU0 is stored in page frame 133 of physical memory, and the CPU-specific data for CPU1 is stored in page frame 135 of physical memory.
The above-described scheme only works well in operating systems that do not support multi-threading. In operating systems that support multi-threading, a single task may include multiple threads that are distributed across the CPUs of the data processing system. Hence, at any point in time, different threads of a single task may be running concurrently on different CPUs.
FIG. 5b illustrates why the above-described scheme will not work in a system having a single image of a multi-threading operating system run on a multi-processor system. Suppose that a first thread of a task is executing on CPU0 and a second thread of the same task is executing on CPU1. Because these threads of computation are part of the same task, the CR3 register 140 of CPUO and the CR3 register 142 of CPU1 both point to the same paging tables 150. Accordingly, the common linear address for the CPU-specific data is mapped to the same paging tables entries 152 for both CPUs. The entries 152 point to a common page frame 154 in physical memory. Therefore, the CPU-specific data of only one of the CPUs may be mapped into the linear address space of the task. This means that the other processor cannot access its CPU-specific data.
A preferred embodiment of the present invention will be described below with reference to a multi-processor system employing INTEL 80386 microprocessors. It should be appreciated that the multi-processor system that is described below is merely illustrative. Those skilled in the art will appreciate that other types of processors (such as an 80286) may be employed and that other multi-processor configurations may be employed.
FIG. 6 depicts an illustrative multi-processor system 150 for practicing the preferred embodiment of the present invention described herein. The multi-processor system 150 includes three CPUs 152, 153 and 154. CPUs 152, 153 and 154 use an addressing architecture like that shown in FIGS. 1-4 when operating in 80386 protected mode. Each CPU 152, 153 and 154 includes registers, such as the segment registers CS, SS, DS, ES, FS and GS as shown in FIG. 3. CPUs 152, 153 and 154 are interconnected with each other and with a memory 158 via an interconnection mechanism 156. The interconnection mechanism 156 may be an interconnection network, bus or other suitable interconnection means.
The multi-processor system 150 executes instructions under the control of a multi-threading operating system 160, that is held in memory 158. This operating system 160 allows multiple threads of a single task to be run in parallel on the respective CPUs 152, 153 and 154. For instance, a first thread of a task may run on CPU 152, while a second thread runs on CPU 153 and a third thread runs on CPU 154.
FIG. 7 illustrates the approach adopted by a preferred embodiment of the present invention described herein to allow CPU-specific data to be stored by the operating system. In the preferred embodiment described herein, a separate GDT is provided for each CPU. GDT1 is provided for CPU 152, GDT2 is provided for CPU 153 and GDT3 is provided for CPU 154. GDT1, GDT2 and GDT3 are used for translation from the virtual address space to the linear address space in a fashion analogous to that described above for the conventional system. At initialization time, the GDTR of each CPU 152, 153 and 154 is filled with a pointer to the GDT for the associated CPU. A particular like-indexed entry for each GDT differs and points to a segment holding CPU-specific data for the associated CPU. The selectors in these like-indexed entries are used by the operating system to access the CPU-specific data for CPU0, CPU1 and CPU2. It should be appreciated that GDT1, GDT2 and GDT3 may also have additional like-indexed entries that hold different selectors. For instance, additional like-indexed entries may hold descriptors for segments holding thread-specific data.
When the operating system seeks to access CPU-specific data, it uses the FS segment register. If the operating system is running and the system is entering kernel space via a trap, the FS segment register is automatically loaded with a constant value, such as "38." This constant value is an index to a GDT entry holding a descriptor for the segment that holds CPU-specific data. Thus, if the operating system needs to access a memory location in the segment that holds CPU-specific data, it uses an address specified as FS:Offset. By adopting such an approach, the single image of the operating system uses the same virtual address on all CPUs to access CPU-specific data.
In contrast, when the operating system is not running and user memory space is being accessed, the FS register is loaded with a different constant value. This constant value is an index to a GDT entry holding a descriptor for a segment in which a thread environment block is stored. Thus, thread-specific data for each is stored at the same virtual address. The thread environment block may be accessed using the FS segment register in a fashion analogous to that described above for the operating system.
The use of the FS segment register as an index is merely illustrative, and storing a constant value of "38" in the register when accessing kernel space is also merely illustrative. Those skilled in the art will appreciate that other registers and other suitable selector values may be used.
Suppose that the operating system is running so that the FS segment register has a value of "38" stored in it. The entry at index "38" of GDT1, the entry at index "38" of GDT2 and the entry at index "38" of GDT3 each point to different sets of entries in the paging tables 176, and each set of entries is mapped into a different page frame in physical memory 180. The entry at index "38" of GDT1 is mapped to page frame 182, which holds the per-CPU data for CPU 152. The entry at index "38" of GDT2 is mapped to page frame 184, which holds per-CPU data for CPU 153, and the entry at index "38" of GDT3 is mapped to page frame 186, which holds per-CPU data for CPU 154. Hence, GDT1, GDT2 and GDT3 are used to store the CPU-specific data for the respective CPUs in different page frames of physical memory but at the same virtual address. Thus, the CPU-specific data for each CPU is only directly addressable and visible by the associated CPU. The problems associated with having a common page table for multiple threads are overcome.
By using GDT1, GDT2 and GDT3 in this manner, no added hardware is required to store CPU-specific data in a multi-threading environment. In addition, since GDTs are part of a flat memory space, they occupy little memory space. Hence, the memory overhead incurred to realize the present invention is miniscule. The run-time cost for the present invention is also miniscule.
While the present invention has been described with reference to a preferred embodiment thereof, those skilled in the art will know of various changes in form and scope that may be made without departing from the spirit of the claim invention as defined in the appended claims. For instance, the present invention need not be used in a paged system; rather, it may also be used in non-paged system.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4442484 *||Oct 14, 1980||Apr 10, 1984||Intel Corporation||Microprocessor memory management and protection mechanism|
|US4539637 *||Aug 26, 1982||Sep 3, 1985||At&T Bell Laboratories||Method and apparatus for handling interprocessor calls in a multiprocessor system|
|US4926322 *||Aug 3, 1987||May 15, 1990||Compag Computer Corporation||Software emulation of bank-switched memory using a virtual DOS monitor and paged memory management|
|US4972338 *||Apr 19, 1988||Nov 20, 1990||Intel Corporation||Memory management for microprocessor system|
|US5144551 *||Jun 13, 1991||Sep 1, 1992||Compaq Computer Corporation||Computer memory management method utilizing segmentation and protection techniques|
|US5255379 *||Dec 28, 1990||Oct 19, 1993||Sun Microsystems, Inc.||Method for automatically transitioning from V86 mode to protected mode in a computer system using an Intel 80386 or 80486 processor|
|US5303378 *||May 21, 1991||Apr 12, 1994||Compaq Computer Corporation||Reentrant protected mode kernel using virtual 8086 mode interrupt service routines|
|US5345588 *||Sep 17, 1992||Sep 6, 1994||Digital Equipment Corporation||Thread private memory storage of multi-thread digital data processors using access descriptors for uniquely identifying copies of data created on an as-needed basis|
|1||*||El Ayat, Khaled & Agarwal, Rakesh, The Intel 80386 Architecture and Implementation , IEEE Micro, Dec. 18, pp. 4 22.|
|2||El-Ayat, Khaled & Agarwal, Rakesh, "The Intel 80386-Architecture and Implementation", IEEE Micro, Dec. 18, pp. 4-22.|
|3||Heller, Vic, "OS/2 Virtual Memory Management", Byte Apr. 88, pp. 227-233.|
|4||*||Heller, Vic, OS/2 Virtual Memory Management , Byte Apr. 88, pp. 227 233.|
|5||Hensler, Carl & Sarno, Ken, "Marryins Unix and the 80386", Byte Apr. 88, pp. 237-244.|
|6||*||Hensler, Carl & Sarno, Ken, Marryins Unix and the 80386 , Byte Apr. 88, pp. 237 244.|
|7||*||Intel, 80286 and 80287 Programmer s Reference Manual, 1987, pp.|
|8||Intel, 80286 and 80287 Programmer's Reference Manual, 1987, pp.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US5860101 *||Dec 17, 1997||Jan 12, 1999||International Business Machines Corporation||Scalable symmetric multiprocessor data-processing system with data allocation among private caches and segments of system memory|
|US5893163 *||Dec 17, 1997||Apr 6, 1999||International Business Machines Corporation||Method and system for allocating data among cache memories within a symmetric multiprocessor data-processing system|
|US5946711 *||May 30, 1997||Aug 31, 1999||Oracle Corporation||System for locking data in a shared cache|
|US6018795 *||Jul 30, 1997||Jan 25, 2000||Bull S.A.||Process and system for obtaining and distributing a ticket identifying a task or event in a multi-node data processing system|
|US6058460 *||Jun 28, 1996||May 2, 2000||Sun Microsystems, Inc.||Memory allocation in a multithreaded environment|
|US6078994 *||May 30, 1997||Jun 20, 2000||Oracle Corporation||System for maintaining a shared cache in a multi-threaded computer environment|
|US6094710 *||Dec 17, 1997||Jul 25, 2000||International Business Machines Corporation||Method and system for increasing system memory bandwidth within a symmetric multiprocessor data-processing system|
|US6182108 *||Jan 31, 1995||Jan 30, 2001||Microsoft Corporation||Method and system for multi-threaded processing|
|US6324623 *||May 30, 1997||Nov 27, 2001||Oracle Corporation||Computing system for implementing a shared cache|
|US6542926 *||Jun 10, 1998||Apr 1, 2003||Compaq Information Technologies Group, L.P.||Software partitioned multi-processor system with flexible resource sharing levels|
|US6542991 *||May 11, 1999||Apr 1, 2003||Sun Microsystems, Inc.||Multiple-thread processor with single-thread interface shared among threads|
|US6574720||Jun 19, 2000||Jun 3, 2003||Oracle International Corporation||System for maintaining a buffer pool|
|US6578122 *||Mar 1, 2001||Jun 10, 2003||International Business Machines Corporation||Using an access key to protect and point to regions in windows for infiniband|
|US6754788 *||Mar 15, 2001||Jun 22, 2004||International Business Machines Corporation||Apparatus, method and computer program product for privatizing operating system data|
|US6801997 *||May 23, 2002||Oct 5, 2004||Sun Microsystems, Inc.||Multiple-thread processor with single-thread interface shared among threads|
|US6845430||Jun 2, 2003||Jan 18, 2005||Oracle International Corporation||System for maintaining a buffer pool|
|US6880068||Apr 2, 2001||Apr 12, 2005||Advanced Micro Devices, Inc.||Mode dependent segment use with mode independent segment update|
|US6886080||Sep 19, 2001||Apr 26, 2005||Oracle International Corporation||Computing system for implementing a shared cache|
|US6901505||Aug 9, 2001||May 31, 2005||Advanced Micro Devices, Inc.||Instruction causing swap of base address from segment register with address from another register|
|US7185185||Mar 31, 2003||Feb 27, 2007||Sun Microsystems, Inc.||Multiple-thread processor with in-pipeline, thread selectable storage|
|US7316021||Feb 17, 2004||Jan 1, 2008||Sun Microsystems, Inc.||Switching method in a multi-threaded processor|
|US7444547 *||Jun 19, 2003||Oct 28, 2008||International Business Machines Corproation||Method, system, and product for programming in a simultaneous multi-threaded processor environment|
|US7587581||Feb 23, 2007||Sep 8, 2009||Sun Microsystems, Inc.||Multiple-thread processor with in-pipeline, thread selectable storage|
|US8166345||Apr 22, 2008||Apr 24, 2012||International Business Machines Corporation||Programming in a simultaneous multi-threaded processor environment|
|US8356210||Mar 15, 2012||Jan 15, 2013||International Business Machines Corporation||Programming in a simultaneous multi-threaded processor environment including permitting apparently exclusive access to multiple threads and disabling processor features during thread testing|
|US8650442||Nov 19, 2012||Feb 11, 2014||International Business Machines Corporation||Programming in a simultaneous multi-threaded processor environment|
|US9218185||Mar 27, 2014||Dec 22, 2015||International Business Machines Corporation||Multithreading capability information retrieval|
|US9354883||Mar 27, 2014||May 31, 2016||International Business Machines Corporation||Dynamic enablement of multithreading|
|US9389862||Mar 27, 2014||Jul 12, 2016||International Business Machines Corporation||Thread context restoration in a multithreading computer system|
|US9417876||Mar 27, 2014||Aug 16, 2016||International Business Machines Corporation||Thread context restoration in a multithreading computer system|
|US9454372||Aug 6, 2015||Sep 27, 2016||International Business Machines Corporation||Thread context restoration in a multithreading computer system|
|US9459875||Aug 6, 2015||Oct 4, 2016||International Business Machines Corporation||Dynamic enablement of multithreading|
|US20020133678 *||Mar 15, 2001||Sep 19, 2002||International Business Machines Corporation||Apparatus, method and computer program product for privatizing operating system data|
|US20020138717 *||May 23, 2002||Sep 26, 2002||Joy William N.||Multiple-thread processor with single-thread interface shared among threads|
|US20030033507 *||Aug 9, 2001||Feb 13, 2003||Mcgrath Kevin J.||Instruction causing swap of segment register and another register|
|US20030191927 *||Mar 31, 2003||Oct 9, 2003||Sun Microsystems, Inc.||Multiple-thread processor with in-pipeline, thread selectable storage|
|US20040162971 *||Feb 17, 2004||Aug 19, 2004||Sun Microsystems, Inc.||Switching method in a multi-threaded processor|
|US20040261078 *||Jun 19, 2003||Dec 23, 2004||International Business Machines Corporation||Method, system, and product for programming in a simultaneous multi-threaded processor environment|
|US20050283602 *||Jun 21, 2004||Dec 22, 2005||Balaji Vembu||Apparatus and method for protected execution of graphics applications|
|US20080189704 *||Apr 22, 2008||Aug 7, 2008||Abou-Emara Luai A||Method, system, and product for programming in a simultaneous multi-threaded processor environment|
|CN100579108C||Feb 21, 2002||Jan 6, 2010||英特尔公司||Method for remote key validation and host computer structure adapter|
|U.S. Classification||718/107, 711/209, 711/173, 711/207, 711/208, 718/106, 711/206|
|International Classification||G06F9/48, G06F9/46|
|Cooperative Classification||G06F9/544, G06F9/4843|
|European Classification||G06F9/54F, G06F9/48C4|
|May 3, 2001||FPAY||Fee payment|
Year of fee payment: 4
|Apr 6, 2005||FPAY||Fee payment|
Year of fee payment: 8
|Apr 1, 2009||FPAY||Fee payment|
Year of fee payment: 12
|Jan 15, 2015||AS||Assignment|
Owner name: MICROSOFT TECHNOLOGY LICENSING, LLC, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034766/0001
Effective date: 20141014