|Publication number||US7962731 B2|
|Application number||US 11/254,320|
|Publication date||Jun 14, 2011|
|Filing date||Oct 20, 2005|
|Priority date||Oct 20, 2005|
|Also published as||CN101331448A, CN101331448B, EP1941350A2, US20070094484, WO2007048128A2, WO2007048128A3|
|Publication number||11254320, 254320, US 7962731 B2, US 7962731B2, US-B2-7962731, US7962731 B2, US7962731B2|
|Original Assignee||Qualcomm Incorporated|
|Export Citation||BiBTeX, EndNote, RefMan|
|Patent Citations (32), Non-Patent Citations (11), Referenced by (1), Classifications (10), Legal Events (2)|
|External Links: USPTO, USPTO Assignment, Espacenet|
The present invention relates generally to the field of processors and in particular to a Backing Store Buffer for a Register Save Engine in a stacked register file architecture.
RISC processors are characterized by relatively small instruction sets, wherein each instruction performs a single instruction, such as an arithmetic, logical, or load/store operation. Arithmetic and logical instructions obtain their operands from, and write their results to, one or more General Purpose Registers (GPR). GPRs are architected registers. That is, they comprise discrete memory locations explicitly identified in the instruction set architecture, and are directly addressed by instructions.
GPRs are often implemented in hardware as an array of high-speed, multi-ported registers, each having a word width defined by the instruction set (e.g., 32 or 64 bits). This array of physical registers is referred to as a Physical Register File. In a direct-mapped register implementation, the number of registers in the Physical Register File exactly matches the number of architected GPRs, and each logical GPR identifier maps to a specific hardware register. For higher performance, and to support superscaler pipelines, many modern processors decouple logical GPR identifiers from physical registers in the Physical Register File. Register renaming, reorder buffers, and the like are techniques known in the art for decoupling logical GPR identifiers from physical registers. Whether directly mapped or renamed, management of the Physical Register File across numerous software procedures is a design challenge, and is often a performance bottleneck.
Most modern software is modular in nature. That is, one procedure may “call,” or transfer control to, another procedure (variously referred to as a function, subroutine, sub-module, or the like). The called procedure may in turn call another procedure, and so on, resulting in procedure nesting, often to a considerable depth. During execution by a processor, each procedure (also referred to as a context) is allocated certain processor resources, including a number of GPRs. The number of GPRs allocated to a procedure may be determined by a compiler's analysis of instructions in the procedure, and may range from a few GPRs to the full architected set of GPRs. When a first procedure calls a second procedure (also known as a context switch), the first, or calling, procedure goes inactive while the second, or called, procedure is allocated separate resources, including its own set of GPRs, and begins execution. When the second procedure completes execution, its resources are deallocated, resources are re-allocated to the calling procedure (if necessary), and the calling procedure resumes execution.
In some prior art processors, such as for example the Intel i-960, a context switch, or new procedure, prompts the processor to store the entire contents of the Physical Register File to memory, making the entire Physical Register File available to the new procedure. When a called procedure completes execution and returns control to its calling procedure, the previously saved register values are restored to the Physical Register File, and execution of the calling procedure continues. The Physical Register File contents are saved to a “Backing Store,” such as system memory (RAM). To mitigate the performance impact of multiple off-chip memory accesses for every context switch when the Backing Store comprises off-chip RAM, a processor may provide one or more “shadow” or “cache” register files—which may comprise actual registers or alternatively may comprise an on-chip cache memory—for storing the contents of the Physical Register File. However, the entire Physical Register File must be stored/retrieved at one time, imposing a performance hit, even in the case of shadow register storage.
A technique employed by many modern processors, that obviates the need to store and retrieve the entire Physical Register File at one time, is known as a stacked register file architecture. In a stacked register file architecture, the high-level processor controller considers the Physical Register File to be a logical stack of infinite depth. This logically infinite stack is implemented in the Physical Register File by incrementally allocating registers to procedures as they are called, and saving the contents of previously allocated registers as necessary.
Initially, both pointers are set to PR0. As procedures are called and registers are allocated thereto, the Top Of Stack pointer moves up. When nearly all available physical registers have been allocated, and a newly called procedure requires more registers than the number of unallocated registers remaining in the Physical Register File 1, the Top Of Stack pointer will “wrap,” and begin allocating registers from the bottom of the Physical Register File 1, beginning with PR0. Before this occurs, however, a sufficient number of registers at the bottom of the Physical Register File 1 must have their contents saved to a Backing Store 3, such as system memory (RAM).
A Register Save Engine 2 interrupts the processor, and executes the instructions necessary to perform register read and memory store operations to save the contents of the least-recently allocated registers at the bottom of the Physical Register File 1 to the Backing Store 3. The Register Save Engine 2 increments the Save/Restore pointer, indicating that registers below the pointer are available for allocation to newly called procedures. When the Register Save Engine 2 completes the register save operation and relinquishes control of the processor, the processor controller allocates registers to the next procedure, and increments the Top Of Stack pointer, wrapping it and incrementing it past the registers whose contents were saved to the Backing Store 3, as those registers are re-allocated and utilized by the called procedure.
Similarly, as a called procedure completes execution and returns control to a calling procedure, the stack is popped, and the registers allocated to the called procedure are de-allocated, or made available for allocation to other procedures. If all data associated with the calling procedure is not still in the Physical Register File 1—that is, if one or more of the calling procedure's registers were re-allocated—the Register Save Engine 2 again interrupts the processor, retrieves the contents of the most recently saved registers from the Backing Store 3, restores the data to the Physical Register File 1, allocates the registers to the calling procedure, and increments the Save/Restore pointer to indicate that the registers are allocated and contain valid data.
The stacked register file system provides optimal performance with a large Physical Register File 1, with a relatively narrow depth of procedure nesting, and/or with relatively few registers allocated to each procedure. Under these conditions, the Top Of Stack pointer simply moves up and down through the Physical Register File 1, allocating and de-allocating registers to procedures as needed, with no delay. However, as the number of procedures increases, and/or one or more procedures requires a large number of registers, the processor experiences numerous interruptions by the Register Save Engine 2, to save data from and restore it to register in the Physical Register File 1 so that registers may be re-allocated to new procedures.
One way to increase performance of a stacked register file system is simply to increase the size of the Physical Register File 1. While this does provide higher performance, the registers in the Physical Register File 1 are usually high-speed, multi-ported registers. Each register may include, e.g., three to five read and write ports. Furthermore, for flexibility in operation scheduling and register allocation, a read port of each physical register must be routed to each execution pipe stage in each pipeline, and the write-back pipe stage in each pipeline must be connected to a write port of each register in the Physical Register File. Thus, increasing the size of the Physical Register File 1 is costly in terms of both gate count and wiring complexity. At any given time, only one procedure is executing, accessing only a small subset of the registers in the Physical Register File 1. Thus, increasing the size of the Physical Register File 1 incurs a significant area and complexity cost, with low utilization of the costly hardware.
In one or more embodiments, a Backing Store Buffer is interposed between a Physical Register File and the Backing Store in a stacked register file architecture. The Backing Store Buffer allows data from registers allocated to inactive procedures to be temporarily stored on-chip, freeing registers in the Physical Register File to be re-allocated to new procedures. When procedures complete and return control to prior, inactive procedures, data associated with the inactive procedures may be retrieved from the Backing Store Buffer, if previously saved, and restored to registers in the Physical Register File, and the registers re-allocated to the inactive procedure. Data need only be written to the Backing Store, incurring the significant performance degradation and power consumption required for off-chip RAM access, when the Backing Store Buffer is full.
One embodiment relates to a method of managing a stacked register file system having a dedicated Backing Store Buffer. One or more registers from a Physical Register File are allocated to a first procedure, and data associated with the first procedure are stored in the allocated registers. Data associated with the first procedure are selectively saved to the dedicated Backing Store Buffer, and one or more registers allocated to the first procedure are released for allocation to a second procedure. Prior to continued execution of the first procedure, data associated with the first procedure are restored from the dedicated Backing Store Buffer to one or more registers and the registers are re-allocated to the first procedure.
Another embodiment relates to a processor. The processor includes a Physical Register File comprising at least as many registers as the number of General Purpose Registers defined in the processor instruction set architecture. The registers are dynamically allocated to software procedures. The processor also includes a Register Save Engine operative to selectively save data from registers allocated to inactive procedures and to restore data to the registers prior to the procedures becoming active. The processor further includes a Backing Store Buffer dedicated to the Register Save Engine and operative to store the data saved from the registers allocated to inactive procedures.
Data is accessed from a Data Cache (D-Cache or D$) 24, with memory addressing and permissions managed by a main Translation Lookaside Buffer (TLB) 26. In various embodiments, the ITLB 22 may comprise a copy of part of the TLB 26. Alternatively, the ITLB 22 and TLB 26 may be integrated. Similarly, in various embodiments of the processor 10, the I-cache 20 and D-cache 24 may be integrated, or unified. Misses in the I-cache 20 and/or the D-cache 24 cause an access to main (off-chip) memory 36, under the control of a memory interface 34.
Pipe stage registers or latches 16 and ALUs 18 may read operands from and/or write results to registers in a Physical Register File 28. The Physical Register File 28 is managed by a Register Save Engine 30, containing a Backing Store Buffer 32. The Backing Store Buffer 32 connects to main memory 36 via memory interface 34. The operation of the Physical Register File 28, Register Save Engine 30, and Backing Store Buffer 32 are described in greater detail below.
The processor 10 may include an Input/Output (I/O) interface 38, controlling access to various peripheral devices 40, 42. Those of skill in the art will recognize that numerous variations of the processor 10 are possible. For example, the processor 10 may include a second-level (L2) cache for either or both the I and D caches. In addition, one or more of the functional blocks depicted in the processor 10 may be omitted from a particular embodiment.
When a procedure is called and requests the allocation of more registers than the number of unallocated registers remaining in the Physical Register File 28, the Register Save Engine 30 saves data associated with inactive procedures—that is, data stored in registers allocated to inactive procedures—from the Physical Register File 28. Register Save Engine 30 increments the Save/Restore pointer, indicating that physical registers below the Save/Restore pointer (and above the Top Of Stack pointer) are available for allocation to new procedures.
Prior to an inactive procedure being activated, the Register Save Engine 30 checks the Physical Register File 28 to ensure that all of the registers that were allocated to the inactive procedure remain allocated to the inactive procedure, and hence contain data associated with the inactive procedure. If one or more of the registers previously allocated to the inactive procedure have been reallocated, then the Register Save Engine 30 restores saved data to available registers in the Physical Register File 28. Upon restoring the data, the Register Save Engine 30 decrements the Save/Restore pointer by the number of registers restored, indicating that the registers above the Save/Restore pointer (and below the Top Of Stack Pointer) are allocated to a procedure. The inactive procedure may then be activated, with all registers previously allocated to it containing the same data they contained when the procedure was inactivated. Those of skill in the art will note that in this discussion, the terms “above” and “below” the pointers are used for convenience, with reference to
To avoid the delay and power consumption associated with the prior art practice of saving and restoring the contents of physical registers directly to a Backing Store 36 such as off-chip RAM, in one or more embodiments the Register Save Engine 30 includes a Backing Store Buffer 32. The Backing Store Buffer 32 temporarily stores data saved from and restored to registers in the Physical Register File 28. The Register Save Engine 30 need only access the Backing Store 36 to save data from the Backing Store Buffer 32 when the Backing Store Buffer 32 is full or approaching capacity. If the size of the Physical Register File 28, combined with the storage capacity of the Backing Store Buffer 32, is greater than or equal to the average stack depth, off-chip accesses to the Backing Store 36 are dramatically reduced.
For even higher performance, in one embodiment the Backing Store Buffer 32 is structured as an array of storage locations (e.g., registers, latches, or SRAM arrays) that have a bit width greater than that of the registers in the Physical Register File 28. In particular, entries in the Backing Store Buffer 32 may have a bit width that is an integral multiple of the width of the Physical Register File 28. This allows data from two or more physical registers to be stored side-by-side in a single Backing Store Buffer 32 entry.
In one embodiment, the integral multiple of bit width is equal to the number of read ports in the Physical Register File 28. For example, if the Physical Register File 28 includes three read ports, the Backing Store Buffer 32 is configured as an array of storage elements, each of which has a bit width three times that of registers in the Physical Register File 28 (as depicted in
The Backing Store Buffer 32 may be implemented in a number of technologies and operational configurations. For example, the Backing Store Buffer 32 may comprise an array of simple, single-port, high-speed registers or latches. Alternatively, the Backing Store Buffer 32 may be implemented as an SRAM array, configured as an n×m array where n is the bit width of each Backing Store Buffer 32 entry, and m is the number of such entries. Regardless of the hardware configuration, the Backing Store Buffer 32 may be implemented in a variety of operational configurations, such as a stack, a FIFO, a cache memory indexed by the context_ID of the procedure associated with the data, or the like.
Regardless of the physical or operational configuration, however, the Backing Store Buffer 32 is dedicated to the Register Save Engine 30. That is, the memory storage locations in the Backing Store Buffer 32 are not part of the instruction set architecture, and may not be addressed by instructions. Additionally, the Backing Store Buffer 32 stores only data contained in registers in the Physical Register File 28 at the time procedures to which those registers were allocated to go inactive. That is, the Backing Store Buffer 32 is separate from scratch registers, cache memory, or any other processor memory or storage locations, whether on- or off-chip. As used herein, the term “dedicated” Backing Store Buffer indicates this physical and functional isolation of the Backing Store Buffer 32 from the rest of the processor 10.
In one embodiment, the Backing Store Buffer 32 is operationally configured as a stack. The Register Save Engine 30 reads data from the Physical Register File 28 and pushes the data onto the top of the stack. Conversely, the Register Save Engine 30 pops the stack to retrieve data to be restored to the Physical Register File 28. As the Backing Store Buffer 32 fills or, in some embodiments, approaches capacity, the Register Save Engine 30 reads data from the bottom of the stack, and stores the data to the Backing Store 36, with may comprise an L1 or L2 cache, or main system memory (e.g., RAM), as depicted in
In one embodiment where the Backing Store Buffer 32 operates as a stack, for optimum performance the Backing Store Buffer 32 is configured as an array of dual-ported registers, with the top and bottom of the stack being maintained by pointers, similar to those described above with respect to the Physical Register File 28. This allows, for example, the Register Save Engine 30 to push data saved from the Physical Register File 28 onto the top of the Backing Store Buffer 32 stack at the same time data is being saved from the bottom of the Backing Store Buffer 32 stack to the Backing Store 36. Similarly, data may be restored from the Backing Store 36 to the bottom of the Backing Store Buffer 32 stack at the same time data is popped from the top of the stack to restore to the Physical Register File 28.
In an alternate embodiment, to reduce circuit complexity and silicon area, the Backing Store Buffer 32 stack is constructed from single-port registers, with the Register Save Engine 30 scheduling writes to and reads from the Backing Store around operations that save data from and restore data to the Physical Register File 28.
A method of operating a stacked register file architecture according to one embodiment is depicted in flow diagram form in
At some point, a procedure is called and register allocation requested (block 40), but insufficient unallocated registers remain in the PRF 28 to satisfy the request (block 42). The RSE 30 then determines how many registers in the PRF 28 must be freed up to satisfy the request, and determines whether a concomitant amount of free space is available in the Backing Store Buffer (BSB) 32 (block 44). If so, at least a sufficient number of registers that are allocated to one or more currently inactive procedures are de-allocated by saving their contents to the BSB 32 (block 48). The RSE 30 then allocates these de-allocated registers, along with existing de-allocated registers in the PRF 28, to the requesting new procedure (block 50), which may proceed with execution and store data in its allocated PRF 28 registers.
If sufficient new procedures are called, and/or if the new procedures require large allocations of registers, the BSB 32 may fill or approach its capacity. In this case, upon a request by a new procedure (block 40), if there are insufficient registers in the PRF 28 (block 42) and insufficient free space in the BSB (block 44), the RSE 30 will save older entries from the BSB 32 to the Backing Store (BS) 36, such as off-chip RAM (block 46). Data may then be saved from the PRF 28 to the BSB 32 (block 48), and the freed PRF 28 registers allocated to the new procedure (block 50). This process may repeat as new procedures are called (block 40).
At some point, rather than calling a new procedure (block 40), an active procedure will terminate, and return control to its calling procedure, which will request reactivation (block 52). The RSE 30 will check to determine if all registers originally allocated to the inactive procedure remain allocated to it in the PRF 28 (block 54). If so, all the data written by the procedure, before it called another procedure and became inactive, remains in the PRF 54 and the procedure may reactivate and resume execution (block 62).
If the RSE 30 saved data from one or more registers originally allocated to inactive procedure and allocated the registers to another procedure, the RSE 30 checks to see if the data is stored in the BSB 32. If so, the RSE 30 reads at least the data associated with the inactive procedure from the BSB 32, and writes it to registers in the PRF 28, allocating the registers to the inactive procedure (block 60). The inactive procedure is then reactivated (block 62).
If data associated with the inactive procedure has been saved from the PRF 28 (block 54), and is not stored in the BSB 32 (block 56), then the data has been saved from the BSB 32 to the BS 36. In this case, the RSE 30 reads at least the data associated with the inactive procedure from the BS 36 and writes it to the BSB 32 (block 58). The RSE 30 then restores the data from the BSB 32 to the PRF 28, allocating the receiving registers to the inactive procedure (block 60) prior to reactivating the procedure (block 62). The reactivated procedure may then call another procedure (block 40), or may itself complete execution and return control to a prior calling procedure (block 52).
Those of skill in the art will recognize numerous obvious variations of and optimizations to the above procedures, in light of the teaching of the present disclosure. For example, when data has been saved all the way to the BS 36, and is required to reactivate a procedure, the RSE 30 may bypass the BSB 32, and write the data directly from the BS 36 to registers in the PRF 28. Additionally, particularly in an embodiment as describe herein where the width of each BSB 32 entry is the width of a PRF 28 register times the number of PRF 28 read ports, data may not be stored from or restored to the PRF 28 (or BSB 32) along procedure boundaries. That is, not all of the data associated with an inactive procedure may be saved from the PRF 28 at the same time. Similarly, when restoring data associated with one inactive procedure to the PRF 28, the RSE 30 may additionally restore data associated with another procedure (with additional data associated with the other procedure remaining stored away in the BSB 32 or BS 36).
By providing dedicated, local, high-speed storage, the Backing Store Buffer 32 allows the Register Save Engine 30 to save and restore data from the Physical Register File 28 without incurring the significant degradation and power consumption associated with writing the saved data to an off-chip Backing Store. The Backing Store Buffer 32 is an economic alternative to increasing the size of the Physical Register File 28, as the Backing Store Buffer 32 does not need to be multi-ported, or connected to pipe stages in one or more execution pipelines.
In fact, the presence of the Backing Store Buffer 32 allows the Physical Register File 28 to include only the number of registers defined as GPRs in the instruction set architecture. That is, since a procedure may theoretically be allocated to all defined GPRs, the number of GPRs in the instruction set architecture places a lower bound on the size of the Physical Register File 28. The Backing Store Buffer 32 of the present invention allows that same number to serve as an upper bound on the size of the Physical Register File 28 to contain silicon area and wiring complexity, while obtaining the high performance and low power consumption of avoiding or minimizing off-chip accesses to a Backing Store 36.
Although the present invention has been described herein with respect to particular features, aspects and embodiments thereof, it will be apparent that numerous variations, modifications, and other embodiments are possible within the broad scope of the present invention, and accordingly, all variations, modifications and embodiments are to be regarded as being within the scope of the invention. The present embodiments are therefore to be construed in all aspects as illustrative and not restrictive and all changes coming within the meaning and equivalency range of the appended claims are intended to be embraced therein.
|Cited Patent||Filing date||Publication date||Applicant||Title|
|US4429363 *||Oct 15, 1981||Jan 31, 1984||International Business Machines Corporation||Method and apparatus for managing data movements from a backing store to a caching buffer store|
|US5530870 *||Jun 5, 1995||Jun 25, 1996||At&T Corp.||Arrangement for efficiently transferring program execution between subprograms|
|US6078970||Oct 15, 1997||Jun 20, 2000||International Business Machines Corporation||System for determining adapter interrupt status where interrupt is sent to host after operating status stored in register is shadowed to host memory|
|US6128728 *||Dec 12, 1997||Oct 3, 2000||Micron Technology, Inc.||Virtual shadow registers and virtual register windows|
|US6243668 *||Aug 7, 1998||Jun 5, 2001||Hewlett-Packard Company||Instruction set interpreter which uses a register stack to efficiently map an application register state|
|US6263401 *||Sep 30, 1997||Jul 17, 2001||Institute For The Development Of Emerging Architectures, L.L.C.||Method and apparatus for transferring data between a register stack and a memory resource|
|US6314513||Nov 23, 1998||Nov 6, 2001||Intel Corporation||Method and apparatus for transferring data between a register stack and a memory resource|
|US6336154 *||Jun 20, 2000||Jan 1, 2002||Hewlett-Packard Company||Method of operating a computer system by identifying source code computational elements in main memory|
|US6408325 *||May 6, 1998||Jun 18, 2002||Sun Microsystems, Inc.||Context switching technique for processors with large register files|
|US6487630 *||Feb 26, 1999||Nov 26, 2002||Intel Corporation||Processor with register stack engine that dynamically spills/fills physical registers to backing store|
|US6578137 *||Aug 8, 2001||Jun 10, 2003||Sun Microsystems, Inc.||Branch and return on blocked load or store|
|US6631452||Apr 28, 2000||Oct 7, 2003||Idea Corporation||Register stack engine having speculative load/store modes|
|US6665793||Dec 28, 1999||Dec 16, 2003||Institute For The Development Of Emerging Architectures, L.L.C.||Method and apparatus for managing access to out-of-frame Registers|
|US6751749||Feb 22, 2001||Jun 15, 2004||International Business Machines Corporation||Method and apparatus for computer system reliability|
|US6799269||Oct 28, 2002||Sep 28, 2004||Micron Technology, Inc.||Virtual shadow registers and virtual register windows|
|US7093110 *||Mar 22, 2002||Aug 15, 2006||Fujitsu Limited||Register file in the register window system and controlling method thereof|
|US7127592||Jan 8, 2003||Oct 24, 2006||Sun Microsystems, Inc.||Method and apparatus for dynamically allocating registers in a windowed architecture|
|US20020056024||Feb 26, 1999||May 9, 2002||Tuan H. Bui||Processor with register stack engine that dynamically spills/fills physical registers to backing store|
|US20020116662||Feb 22, 2001||Aug 22, 2002||International Business Machines Corporation||Method and apparatus for computer system reliability|
|US20030051124||Oct 28, 2002||Mar 13, 2003||Dowling Eric M.||Virtual shadow registers and virtual register windows|
|US20040064632 *||Sep 15, 2003||Apr 1, 2004||Derrick Lin||Register stack engine having speculative load/store modes|
|US20040133766 *||Jan 8, 2003||Jul 8, 2004||Abraham Santosh G.||Method and apparatus for dynamically allocating registers in a windowed architecture|
|US20060047921 *||Sep 1, 2005||Mar 2, 2006||Hewlett-Packard Development Company, L.P.||Method and apparatus for managing storage used by a processor when processing instructions|
|US20060294344 *||Jun 28, 2005||Dec 28, 2006||Universal Network Machines, Inc.||Computer processor pipeline with shadow registers for context switching, and method|
|US20070106885||Nov 10, 2005||May 10, 2007||Bohuslav Rychlik||Expansion of a stacked register file using shadow registers|
|USH1291||Dec 20, 1990||Feb 1, 1994||Hinton Glenn J||Microprocessor in which multiple instructions are executed in one clock cycle by providing separate machine bus access to a register file for different types of instructions|
|EP0676691A2||Mar 27, 1995||Oct 11, 1995||Hewlett-Packard Company||Apparatus for register saving and restoring in a digital computer|
|EP0955583A2||May 5, 1999||Nov 10, 1999||Sun Microsystems, Inc.||Context switching technique for processors with large register files|
|KR100868410B1||Title not available|
|RU2193228C2||Title not available|
|WO1996021186A2||Nov 16, 1995||Jul 11, 1996||Philips Electronics Nv||Plural multiport register file to accommodate data of differing lengths|
|WO2001082059A2||Apr 26, 2001||Nov 1, 2001||Sun Microsystems Inc||Method and apparatus to improve context switch times in a computing system|
|1||*||"Intel IA-64 Architecture Software Developer's Manual" vol. 1: IA-64 Application Architecture; Rev. 1.1, Jul. 2000; pertinent pp. 3-2 to 3-6, 4-1 to 4-4.|
|2||*||"Intel IA-64 Architecture software Developer's Manual" vol. 2: IA-64 System Architecture; Rev. 1.1, Jul. 2000. Pertinent pp. 6-1 to 6-16.|
|3||*||"Microsoft Computer Dictionary, Fifth Edition" pertinent p. 76.|
|4||International Preliminary Report on Patentability-PCT/US06/060128, The International Bureau of WIPO, Geneva Switzerland- Apr. 23, 2008.|
|5||International Preliminary Report on Patentability—PCT/US06/060128, The International Bureau of WIPO, Geneva Switzerland— Apr. 23, 2008.|
|6||International Search Report-PCT/US06/060128, International Search Authority-European Patent Office- May 7, 2007.|
|7||International Search Report—PCT/US06/060128, International Search Authority—European Patent Office— May 7, 2007.|
|8||*||Jayaraj et al. "Shadow Register File Architecture: A mechanism to reduce context switch latency" Published: 2003, IEEE.|
|9||Juame Abella; Antonio Gonzales "On Reducing Register Pressure and Energy in Multiple-Banked Register Files".|
|10||Written Opinion-PCT/US06/060128, International Search Authority-European Patent Office-May 7, 2007.|
|11||Written Opinion—PCT/US06/060128, International Search Authority—European Patent Office—May 7, 2007.|
|Citing Patent||Filing date||Publication date||Applicant||Title|
|US20130166810 *||Aug 1, 2012||Jun 27, 2013||Electronics And Telecommunications Research Institute||Apparatus for processing register window overflow and underflow|
|U.S. Classification||712/228, 712/E09.027, 712/E09.024|
|Cooperative Classification||G06F9/30134, G06F9/30123, G06F9/30116|
|European Classification||G06F9/38H2, G06F9/30R5S, G06F9/30R5C|
|Nov 10, 2005||AS||Assignment|
Owner name: QUALCOMM INCORPORATED, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:RYCHLIK, BOHUSLAV;REEL/FRAME:016998/0055
Effective date: 20051018
|Nov 24, 2014||FPAY||Fee payment|
Year of fee payment: 4