ACM Home Page
Please provide us with feedback. Feedback
Integrating superscalar processor components to implement register caching
Full text PdfPdf (146 KB)
Source International Conference on Supercomputing archive
Proceedings of the 15th international conference on Supercomputing table of contents
Sorrento, Italy
Pages: 348 - 357  
Year of Publication: 2001
ISBN:1-58113-410-X
Authors
Matthew Postiff  Advanced Computer Architecture Laboratory, University of Michigan, 1301 Beal Ave., Ann Arbor, MI
David Greene  Advanced Computer Architecture Laboratory, University of Michigan, 1301 Beal Ave., Ann Arbor, MI
Steven Raasch  Advanced Computer Architecture Laboratory, University of Michigan, 1301 Beal Ave., Ann Arbor, MI
Trevor Mudge  Advanced Computer Architecture Laboratory, University of Michigan, 1301 Beal Ave., Ann Arbor, MI
Sponsor
SIGARCH: ACM Special Interest Group on Computer Architecture
Publisher
ACM  New York, NY, USA
Bibliometrics
Downloads (6 Weeks): 3,   Downloads (12 Months): 24,   Citation Count: 9
Additional Information:

abstract   references   cited by   index terms   collaborative colleagues   peer to peer  

Tools and Actions: Review this Article  
Save this Article to a Binder    Display Formats: BibTex  EndNote ACM Ref   
DOI Bookmark: Use this link to bookmark this Article: http://doi.acm.org/10.1145/377792.377859
What is a DOI?

ABSTRACT

A large logical register file is important to allow effective compiler transformations or to provide a windowed space of registers to allow fast function calls. Unfortunately, a large logical register file can be slow, particularly in the context of a wide-issue processor which requires an even larger physical register file, and many read and write ports. Previous work has suggested that a register cache can be used to address this problem. This paper proposes a new register caching mechanism in which a number of good features from previous approaches are combined with existing out-of-order processor hardware to implement a register cache for a large logical register file. It does so by separating the logical register file from the physical register file and using a modified form of register renaming to make the cache easy to implement. The physical register file in this configuration contains fewer entries than the logical register file and is designed so that the physical register file acts as a cache for the logical register file, which is the backing store. The tag information in this caching technique is kept in the register alias table and the physical register file. It is found that the caching mechanism improves IPC up to 20% over an un-cached large logical register file and has performance near to that of a logical register file that is both large and fast.


REFERENCES

Note: OCR errors may be found in this Reference List extracted from the full text article. ACM has opted to expose the complete List rather than only correct and linked references.

 
1
Douglas C. Burger and Todd M. Austin. The SimpleScalar Tool Set, Version 2.0. University of Wisconsin, Madison Tech. Report. June, 1997.
2
 
3
 
4
 
5
Linley Gwenapp. Digital 21264 Sets New Standard. Microprocessor Report, Vol. 10, No. 14. October 28, 1996, pp. 11-16.
 
6
Intel IA-64 Application Developer's Architecture Guide. May 1999. Order Number: 245188-001. Available at http://developer.intel.com/design/ia64/devinfo.htm.
 
7
 
8
 
9
 
10
 
11
 
12
 
13
Matthew Postiff, David Greene, Charles Lefurgy, Dave Helder, Trevor Mudge. The MIRV SimpleScalar/PISA Compiler. University of Michigan CSE Technical Report CSE-TR-421- 00, April 2000. Available at {22}.
 
14
Matthew Postiff, David Greene, and Trevor Mudge. Exploiting Large Register Files in General Purpose Code. University of Michigan Technical Report CSE-TR-434-00, October 2000. Available at {22}.
 
15
 
16
17
 
18
 
19
 
20
 
21
Robert Yung and Neil C. Wilhelm. Caching Processor General Registers. Sun Microsystems Laboratories Tech. Report. June, 1995.
 
22

CITED BY  9
 
 
 
 
 

Collaborative Colleagues:
Matthew Postiff: colleagues
David Greene: colleagues
Steven Raasch: colleagues
Trevor Mudge: colleagues

Peer to Peer - Readers of this Article have also read: