Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #1572

Re: Anyone take a serious look at partitioned register sets?

Show all headers | View raw

On 5/13/2011 12:13 PM, Paul A. Clayton wrote:
> On Thursday, May 12, 2011 10:32:47 PM UTC-4, Andy Krazy Glew wrote:
>> On 5/12/2011 8:19 AM, Paul A. Clayton wrote:
> [snip]
>>> It seems that the EV8 used a register cache rather than a
>>> traditional forwarding network.
>>
>> I did not know this.  Are you sure?  Evidence?
>>
>> In fact, I thought I was the first guy crazy enough to propose a
>> register file cache. In fact, I took grief from many ex DEC Alpha guys
>> for it.
>
> Ronald P. Preston et al., "Design of an 8-wide Superscalar RISC
> Microprocessor with Simultaneous Multithreading" (ISSCC 2002)
> http://www.imec.be/elela/HD03/examens/2003/D20_1.pdf
>
> "Smaller register caches added to the integer and floating-point
> execution units reduce the performance penalty associated with
> this additional latency. The register caches store copies of the
> last 8 cycles of generated results, act as local bypass result
> multiplexers, and align result write-back to the main register
> file avoiding contention for the 8 write ports due to
> instruction latency"

Well, I predate this publication, and the EV8, but they were probably 
thinking of the idea about the same time I was.  So I probably wasn't 
firrst.

Cool.  I'm not crazy.  If I had known that Alpha was doing it, I might 
have had an easier task of selling the idea.  Usually it is easier to 
sell an idea that others have had, rather than one you came up with 
yourself.

Although it is possible that the DEC guys who dissed the [[RF cache]] 
knew about this, and also knew about its problems.

By the way, I call what the EV8 paper did a [[bypass cache]] rather than 
a [[register file cache]].

It is organized temporally, by time of writeback - "the last 8 cycles of 
generated results".  I use the term [[RF cache]] to refer to a cache 
that is organized more like a traditional cache.  Although I suppose 
than any fully associative cache with true LRU is really organized 
temporally - but a bypass cache is organized by time of creation, not by 
time of use.  Actually, what we want is an RF cache organized by time 
when use will stop. Bypass cache  is a heiristic, but not necessarily 
the best.

(By the way, I quite like things that say "This register is dead". 
Rather like a hint zero clear that indicates nobody is going to use it 
any more.)

More precisely:

* We might use [[RF cache]] as a generic term, for anything that has a 
smaller faster structure in front of a big slower RF.

** [[bypass cache]] is organized temporally - i.e. replaces an entry 
when it is no longer one of the N oldest in terms of writeback. 
Probably has a CAM index.

** a more traditional [[RF cache]] might be
*** fully associative, organized by time or use or predicted end of use
*** set associative
**** spatially indexed by logical register number, or physical register 
number. Possibly both.
**** LRU or other replacement.
*** in either case, probably CAM indexed by physical register number.

(Yes, I know that I am using the term [[RF cache]] at two places in this 
hierarchy.  Happens.)

** another RF-cache-like  structure is to have a smaller RF, indexed by 
yet another physical register name.  Not CAM indexed, but RAM indexed.
*** When you move  data from the large array to the small array, you map 
the larger preg# to the smalller preg#.
*** uops get renamed with both the large preg#, andthe smalll preg#, 
which may pass in and  out of use.

I like eliminating CAMs whenever possible.  However, if the RF  cache 
preg# is not known, or may change, then you may have to look it up later 
- and that throws away the benefit of having a register renaming map 
whose size is equal to the smaller logical register namespace, rather 
than the larger physical register namespace.  The easy way to handle 
this just turns the map into a CAM, as opposed to the  data lookup.

Back to comp.arch | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: Anyone take a serious look at partitioned register sets? "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-05-13 12:13 -0700
  Re: Anyone take a serious look at partitioned register sets? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-14 12:58 -0700

csiph-web