Groups | Search | Server Info | Keyboard shortcuts | Login | Register


Groups > comp.arch > #5779

Re: Register file splits, a new look.

From MitchAlsup <MitchAlsup@aol.com>
Newsgroups comp.arch
Subject Re: Register file splits, a new look.
Date 2012-02-06 09:29 -0800
Organization http://groups.google.com
Message-ID <3677258.856.1328549340657.JavaMail.geo-discussion-forums@yqcg21> (permalink)
References <ggtgp-1DA77E.06332706022012@netnews.mchsi.com>

Show all headers | View raw


In my opinion, 8 address registers is too few, and at least one of the LivermoreLoops codes requires a couple more. So if you do address registers, do more than 8.

On the other hand, if you have a subset of the integer registers that can be used in address arithmetic, you can often easily get the instructions to deposit an integer result in an address register just before it gets used. This saves the bit in the instruction and does not make the compiler go thrugh Herculean effort to effectively utilize the integer register file.

But, overall, given that you have enough registers (minimum 32 registers of 64-bits each) unification brings certain advantages. You can perform bit manipulation on FP exponents (for I/O and other purposes), you can alias FP parameters with integer types on the opposite sides of call/return interfaces, and share renamed registers for those sections that are integer dense and those places that are FP dense with ease.

Thus, if you are looking at a general purpose computational core, unify the main register file, and THEN extend the architecture with a short vector register file (SSE) that uses its own (sub)instruction set. Many normal FP codes will migrate naturally over to the short vector register set, leaving the whole integer file for addresses and bookeeping. Once the compiler is adept at doing FP in short vector file, the FP file becomes mostly redundant. BUT this does mean the short vector file and (sub)instruction set must easily express normal FP codes efficiently.

Mitch

Back to comp.arch | Previous | NextPrevious 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