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

Groups > comp.arch > #5845

Re: Register file splits, a new look.

Show all headers | View raw

On Thursday, February 9, 2012 4:19:59 AM UTC-6, Torben Ægidius Mogensen wrote:
> A disadvantage of a single unified register file is that you need more
> read/write ports to support the same total number of reads and writes
> per cycle.

Important side note: Onme can increase the number of read ports rather easily by replication. It is much more difficult to increase the number of write ports.

>             A disadvantage of splitting the register file is that you
> may underutilize some banks, for example in code that does not use FP,
> and at the same time not have enough of the other kind.

In Great Big OoO machines, the cost is not in the architectural registers that go underutilized, but in that the renamable register go underutilized. So, for a 6-wide 16-deep BGOoO machine one could get buy with 128 registers in a single renamable pool, or one would have to use two files of 128 registers each. You could argue that you could use one pool of 128 and another pool of 96--but at this point it is cheeper just to step and repeat the register file than to build one that is just a little different.
 
> An advantage of a split file is also that you need fewer bits in the
> instruction word to specify a register, as the bank will be implied by
> the instruction.

32-unified 64-bit registers is enough for any of the high throughput FP applications. Thus, you don't save a bit.

In addition, you have to maintain two MAPs (and recover 2 MAPs) and access both maps each instruction decode cycle. IN one design I did, the power in the MAPs were almost equivalent to the power consumed in the files themselves!

>                   On the other hand, you may have to essentially
> duplicate instructions for several banks, as common operations like
> register moves and equality tests are needed for all types of registers.

Not to mention all the software idiosyncrasies we have had to teach the compiler over the years to deal with::

F(int i)
{ return i+1 ;}
--------separate compilation unit-------------
main(int argc, *char[] argv)
{ float x = 0.0;
  float F();
  float y = F(x);
}

Sure its a typing issue, but sometimes (about once a year) one needs to do stuff like this! In this case, y is x+ulp.

> So there is no clear case either way, and it may depend a lot on the
> number of registers.  If you want to keep the total number of registers
> down, a unified file is probably the best bet, as the risk of running
> out of registers in one bank while having spare registers in another is
> higher than if you have plenty of registers.  So you could see a unified
> register file as a way of reducing the register total (at the cost of
> adding more read/write ports and complicating the data paths to the
> functional units).

As indicated before, the problem of keeping track of the registers is consuming a commensurate amount of power as is accessing the register files themselves. This occurs because the MAPs have to be setup for maximal decoder throughput (3 to 4 IPC) while the register files are utilized (on average) at 1.0 IPC.

But I don't see the argument about physical registers at all! The argument is about architectural registers. Consider a GBOoO machine that has to be coOptimized for both high throughput integer and high throughput FP. 

In the unified approach, it takes two files of 128 registers each (12 read, 6 write) ports to support the entire agregate bandwidth for integer codes or for FP codes and one 128 entry MAP.

In the separate approach, it still requires 2 files of 128 registers each to support the integer throughput, and then it takes another 2 files of 96-entries to support the FP throughput requirements. And you require 2 MAPs. The reason it takes 2 files here is that you still have to absorb and deliver memory (2 Load 1 store per cycle) requests to the FP files as the FP units (Add, Mul, Div; or 2 MACs and a DIV) are crunching along.

In several machines I have worked on, the register files (plus reorder buffers, and buffering) were bigger than the computational units attached to them! All of these were separate file machines. A lot of power is heading down this hole.
 
> An idea could be to split the register file not by type but into, say,
> even and odd-numbered registers, each with its own rename set.  Each
> instruction that reads two registers is made to read one from each file.

I cannot comment on this because I have never "thought down this path". Suffice to say it has merit and pitfalls.

Mitch

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

Thread

Register file splits, a new look. Brett Davis <ggtgp@yahoo.com> - 2012-02-06 06:33 -0600
  Re: Register file splits, a new look. MitchAlsup <MitchAlsup@aol.com> - 2012-02-06 09:29 -0800
    Re: Register file splits, a new look. Brett Davis <ggtgp@yahoo.com> - 2012-02-07 07:08 -0600
  Re: Register file splits, a new look. torbenm@diku.dk (Torben Ægidius Mogensen) - 2012-02-09 11:19 +0100
    Re: Register file splits, a new look. MitchAlsup <MitchAlsup@aol.com> - 2012-02-09 12:12 -0800
      Re: Register file splits, a new look. "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-09 15:27 -0800
        Re: Register file splits, a new look. MitchAlsup <MitchAlsup@aol.com> - 2012-02-09 15:52 -0800
      Re: Register file splits, a new look. nmm1@cam.ac.uk - 2012-02-10 08:07 +0000
        Re: Register file splits, a new look. "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-10 06:37 -0800
      Re: Register file splits, a new look. Terje Mathisen <"terje.mathisen at tmsw.no"> - 2012-02-10 09:36 +0100
      Re: Register file splits, a new look. Brett Davis <ggtgp@yahoo.com> - 2012-02-10 12:22 -0600
        Re: Register file splits, a new look. MitchAlsup <MitchAlsup@aol.com> - 2012-02-10 12:26 -0800
          Re: Register file splits, a new look. Brett Davis <ggtgp@yahoo.com> - 2012-02-11 07:25 -0600
            Re: Register file splits, a new look. Brett Davis <ggtgp@yahoo.com> - 2012-02-16 17:17 -0600
            Re: Register file splits, a new look. MitchAlsup <MitchAlsup@aol.com> - 2012-02-16 16:25 -0800
              Re: Register file splits, a new look. Brett Davis <ggtgp@yahoo.com> - 2012-02-17 14:08 -0600
                Re: Register file splits, a new look. MitchAlsup <MitchAlsup@aol.com> - 2012-02-28 08:54 -0800
                Re: Register file splits, a new look. Brett Davis <ggtgp@yahoo.com> - 2012-02-28 19:33 -0600

csiph-web