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

Groups > comp.arch > #5657 > unrolled thread

Are rotating register files still a bad idea?

Back to article view | Back to comp.arch

Contents

  Are rotating register files still a bad idea? Brett Davis <ggtgp@yahoo.com> - 2012-02-02 02:16 -0600
    Re: Are rotating register files still a bad idea? "Paul A. Clayton" <paaronclayton@gmail.com> - 2012-02-02 07:41 -0800
    Re: Are rotating register files still a bad idea? Nomen Nescio <nobody@dizum.com> - 2012-02-02 19:04 +0100
      Re: Are rotating register files still a bad idea? Brett Davis <ggtgp@yahoo.com> - 2012-02-02 23:16 -0600
        Re: Are rotating register files still a bad idea? Fritz Wuehler <fritz@spamexpire-201202.rodent.frell.theremailer.net> - 2012-02-03 18:19 +0100
          Re: Are rotating register files still a bad idea? Anne & Lynn Wheeler <lynn@garlic.com> - 2012-02-03 13:09 -0500
            Re: Are rotating register files still a bad idea? Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2012-02-03 12:28 -0800
            Re: Are rotating register files still a bad idea? MitchAlsup <MitchAlsup@aol.com> - 2012-02-03 13:04 -0800
          Re: Are rotating register files still a bad idea? Thomas Womack <twomack@chiark.greenend.org.uk> - 2012-02-03 19:15 +0000
            Re: Are rotating register files still a bad idea? Mark Thorson <nospam@sonic.net> - 2012-02-03 13:08 -0800
              Re: Are rotating register files still a bad idea? Thomas Womack <twomack@chiark.greenend.org.uk> - 2012-02-03 22:21 +0000
                Re: Are rotating register files still a bad idea? Mark Thorson <nospam@sonic.net> - 2012-02-03 18:42 -0800
                  Re: Are rotating register files still a bad idea? Glen Overby <coreSPAMsample@charter.net> - 2012-03-01 18:18 -0600
              Re: Are rotating register files still a bad idea? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-04 13:26 +0000
              Re: Are rotating register files still a bad idea? Fritz Wuehler <fritz@spamexpire-201202.rodent.frell.theremailer.net> - 2012-02-05 00:58 +0100
            Re: Are rotating register files still a bad idea? Nomen Nescio <nobody@dizum.com> - 2012-02-04 21:00 +0100
              Re: Are rotating register files still a bad idea? Brett Davis <ggtgp@yahoo.com> - 2012-02-05 00:35 -0600
          Re: Are rotating register files still a bad idea? Quadibloc <jsavard@ecn.ab.ca> - 2012-02-03 10:11 -0800
    Re: Are rotating register files still a bad idea? jgk@panix.com (Joe keane) - 2012-02-03 23:20 +0000
    Re: Are rotating register files still a bad idea? "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-03 22:54 -0800
      Re: Are rotating register files still a bad idea? Brett Davis <ggtgp@yahoo.com> - 2012-02-04 07:15 -0600
        Re: Are rotating register files still a bad idea? "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-05 13:49 -0800
          Re: Are rotating register files still a bad idea? Brett Davis <ggtgp@yahoo.com> - 2012-02-06 05:36 -0600
            Re: Are rotating register files still a bad idea? "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-02-06 18:46 -0800
              Re: Are rotating register files still a bad idea? Brett Davis <ggtgp@yahoo.com> - 2012-02-28 20:02 -0600
                Re: Are rotating register files still a bad idea? Brett Davis <ggtgp@yahoo.com> - 2012-03-07 22:35 -0600
                  Re: Are rotating register files still a bad idea? "Andy (Super) Glew" <andy@SPAM.comp-arch.net> - 2012-03-08 07:25 -0800
          Re: Are rotating register files still a bad idea? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-02-06 12:49 +0000
        Re: Are rotating register files still a bad idea? Quadibloc <jsavard@ecn.ab.ca> - 2012-02-04 11:14 -0800
    Re: Are rotating register files still a bad idea? Michael S <already5chosen@yahoo.com> - 2012-02-03 06:04 -0800
    Re: Are rotating register files still a bad idea? MitchAlsup <MitchAlsup@aol.com> - 2012-02-03 12:20 -0800

Page 1 of 2  [1] 2  Next page →

#5657 — Are rotating register files still a bad idea?

Are rotating register files still a bad idea?

Rotating register files used to mean slow clock speeds.
SPARC has had competitive clocks for the past decade,
largely because everyone hit a thermal brick wall...

I assume that if that brink wall breaks, rotating register files
are back to being doomed, but that looks unlikely.

Does rotating register files buy you anything net after costs,
or is it just a fiasco in the age of modern OoO pipelines?

[toc] | [next] | [standalone]

#5661

On Feb 2, 3:16 am, Brett Davis <gg...@yahoo.com> wrote:
> Are rotating register files still a bad idea?
>
> Rotating register files used to mean slow clock speeds.
> SPARC has had competitive clocks for the past decade,
> largely because everyone hit a thermal brick wall...
>
> I assume that if that brink wall breaks, rotating register files
> are back to being doomed, but that looks unlikely.
>
> Does rotating register files buy you anything net after costs,
> or is it just a fiasco in the age of modern OoO pipelines?

Tensilica's XTensa ISA uses a rotating register file.
The main advantages are in avoiding save/restore
traffic and in reducing code size (by removing
explicit stores/loads and possibly by encouraging
function calls [which may also reduce register
pressure, allowing 16 visible registers to be
enough further enhancing code density]).  XTensa is
very unlikely to be implemented as a complex OoO
processor.

For use as a register stack (but not software
pipelining), an alternative which might play nicer
with OoO execution would be a variable block
save/restore.  I.e., a selection of blocks of
(e.g.) four registers could be saved and
restored.

In an in-order design, there would be the
equivalent of a RAT where each block of savable
registers would have a remapping entry (and
possibly each register have an is_zero bit to
avoid actual register clearing or being able to
read old values--which may be from another
context) with a free list of available register
blocks and a stack of old mappings.

Alternatively, an in-order design might treat
the saves and restores as store/load block of
registers instructions.

In an OoO design, the RAT might be extended to
allow block reads and writes (similar to how
some microarchitectures checkpoint branches);
a save would read the block(s) (and probably
write the block(s) with a special is_zero
register name--using all zeros [or all one's]
for this register name might make the write a
relatively low overhead operation), and a
restore would write a 'checkpoint' entry into
the RAT.  (It might even be practical/useful
to share the checkpointing structure between
branches and the register save.)

(I suppose a SPARC could use a similar method
with something a little like Sum-Addressed
Memory in the RAT to add 0 or 16 to the
architected register names.)

One advantage that a register stack could have
is that alignment of the save region could be
guaranteed and large chunks could be saved
with less overhead than discrete store
operations.  In addition, saves and restores
have much more predictable access, allowing
streaming optimizations to be used, hiding
latency and avoiding conflict in the main
L1 Dcache.  (A RISC orientation would
provide primitives that mark access pattern
for loads and stores, but even Itanium only
provides non-temporal in level N annotations
for allocation [not access, though such
might be used for access guiding that has
the problem that the annotations may be used
as 'EvictMe' hints while expecting a L1 hit].)

SPARC's save/restore has an advantage in
that it is decoupled from the call/return,
so such could be used in the middle of a
function to allow saving and restoring
registers.

With respect to the question of whether a
rotating register file has any advantages,
the answer would depend on the experience
of the implementers and the expected
complexity of the designs (and the
resources--human, time, and tools--available
to deal with such complexity).  I suspect
Tensilica made a reasonable choice.  For a
GPU (which might be very free to innovate at
the ISA level), I would be skeptical of the
benefits because supporting more threads
would be better than reducing overhead for
a single thread.

If the target was a more flexible processor
(one that could benefit from reduced store
and load traffic or support more threads or
support a larger OoO window), then some
kind of register save/restore specialization
might be worth considering.

(Note also that there are techniques like 3D
register files and checkpoint registers that
reduce the cost of temporarily non-accessible
registers in a highly-ported register file.)

That is a long way of saying "I don't know."

[toc] | [prev] | [next] | [standalone]

#5664

Brett Davis <ggtgp@yahoo.com> wrote:

> Are rotating register files still a bad idea?
> 
> Rotating register files used to mean slow clock speeds.
> SPARC has had competitive clocks for the past decade,
> largely because everyone hit a thermal brick wall...
> 
> I assume that if that brink wall breaks, rotating register files
> are back to being doomed, but that looks unlikely.

SPARC is on the way out for marketing reasons anyway, so whatever the answer
is it is probably academic.

> Does rotating register files buy you anything net after costs,
> or is it just a fiasco in the age of modern OoO pipelines?

From the programmer's view it helps in that it provides a reasonable,
uniform calling convention as opposed to Intel's bucket-o-shit approach
resulting in every OS that uses it having it's own bizarre calling
conventions. Intel also makes assembly coding harder (not that many people
use it nowadays) because of how few registers they have (AMD64 helps a bit
but not enough) and how likely it is to step on one accidentally, since
there isn't an established save/restore sequence or calling
sequence. Looking at it it's easy to see it was a big ad-hoc failure. Not
sure from a performance perspective but as an assembly programmer I like the
uniformity and sensible SPARC approach much more than Intel's chaotic trash
heap. Since 99.9% of code for those two processors is written in C it mostly
doesn't matter since C coders have no idea what goes on under the bonnet.

[toc] | [prev] | [next] | [standalone]

#5673

In article <e81f2e1c93cc68818cbc752bf6c316ec@dizum.com>,
 Nomen Nescio <nobody@dizum.com> wrote:

> Brett Davis <ggtgp@yahoo.com> wrote:
> 
> > Are rotating register files still a bad idea?
> > 
> > Rotating register files used to mean slow clock speeds.
> > SPARC has had competitive clocks for the past decade,
> > largely because everyone hit a thermal brick wall...
> > 
> > I assume that if that brink wall breaks, rotating register files
> > are back to being doomed, but that looks unlikely.
> 
> SPARC is on the way out for marketing reasons anyway, so whatever the answer
> is it is probably academic.

SPARC is in the same boat as the 370 and POWER, mainframe/mini margins
will keep SPARC alive for at least 20 years.

[toc] | [prev] | [next] | [standalone]

#5682

Brett Davis <ggtgp@yahoo.com> wrote:

> > SPARC is on the way out for marketing reasons anyway, so whatever the answer
> > is it is probably academic.
> 
> SPARC is in the same boat as the 370 and POWER, mainframe/mini margins
> will keep SPARC alive for at least 20 years.

I don't believe that and I don't understand what you said about mainframe.

SPARC is not a mainframe processor.

System Z (what you are calling 370) is actively developed and installed at
10s of thousands of sites as a primary machine. It's a lot easier to migrate
C code that runs on SPARC to Intel and replace a server farm than it is to
migrate assembler and COBOL that runs on IBM and there are advantages to IBM
OS and hardware that SPARC doesn't offer over its competition.

I personally liked SPARC well and am sorry to see it go especially since the
alternative is Intel. But go it will, and it won't take 20 years. System Z
on the other hand will be here for the foreseeable future. POWER will
probably also, but I know less about that.

[toc] | [prev] | [next] | [standalone]

#5685

Fritz Wuehler <fritz@spamexpire-201202.rodent.frell.theremailer.net>
writes:
> System Z (what you are calling 370) is actively developed and installed at
> 10s of thousands of sites as a primary machine. It's a lot easier to migrate
> C code that runs on SPARC to Intel and replace a server farm than it is to
> migrate assembler and COBOL that runs on IBM and there are advantages to IBM
> OS and hardware that SPARC doesn't offer over its competition.

current estimate is that there are 10,000 mainframes installed at
4000-5000 customers (I know some large financial institutions with
50-100 machines).
http://articles.economictimes.indiatimes.com/2010-08-10/news/27620495_1_mainframe-ibm-big-challenge

I've conjectured that heavy financial industry dependency on mainframes
contributed to Gerstner taking the job to resurrect IBM in the mid-90s
... although the business does continue mainframes ... its revenue is
now 83% software and services ... and everything else (including all
hardware platforms) is 17%. recent reference in ibm-main mailing list
http://www.garlic.com/~lynn/2012.html#20

a couple other refs from (linkedin) Greater IBM (current/former
employees)
http://www.garlic.com/~lynn/2012.html#57
http://www.garlic.com/~lynn/2012.html#104

other recent posts on the subject
http://www.garlic.com/~lynn/2012.html#45
http://www.garlic.com/~lynn/2012.html#92

recent mainframe z196 is rated at 50BIPS with 80 processors (previous
mainframe z10 was 24BIPS with 64 processors) ... or if every mainframe
in the world upgraded to maximum 80 processor configuration ... that
works at to 500TIPS
http://www.garlic.com/~lynn/2012b.html#28
http://www.garlic.com/~lynn/2012b.html#30

compared to on-demand supercomputer from Amazon cloud at 240TIPS (which
would rank 42nd in the world) ... lots of cloud mega-datacenters may
individually have more processing power than the aggregate of every
mainframe in the world today.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#5688

On 2/3/2012 10:09 AM, Anne & Lynn Wheeler wrote:
snip

> I've conjectured that heavy financial industry dependency on mainframes
> contributed to Gerstner taking the job to resurrect IBM in the mid-90s
> ... although the business does continue mainframes ... its revenue is
> now 83% software and services ... and everything else (including all
> hardware platforms) is 17%.

But this is somewhat ambiguous.  Where are the payments for Zos, CICS, 
IMS, etc. counted?  If it is in the software part, then yes, but that 
portion is clearly dependent on the mainframe business and would change 
the numbers.


-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

[toc] | [prev] | [next] | [standalone]

#5765

Some perspective:

On Friday, February 3, 2012 12:09:06 PM UTC-6, Anne & Lynn Wheeler wrote:
> current estimate is that there are 10,000 mainframes installed at
> 4000-5000 customers 

This is 1/3rd of a day in the FAB for AMD and less than 1 hour for Intel.
And that is the entirety of the installed base!
 
> recent mainframe z196 is rated at 50BIPS with 80 processors (previous
> mainframe z10 was 24BIPS with 64 processors) ... or if every mainframe
> in the world upgraded to maximum 80 processor configuration ... that
> works at to 500TIPS

> compared to on-demand supercomputer from Amazon cloud at 240TIPS (which
> would rank 42nd in the world) ... lots of cloud mega-datacenters may
> individually have more processing power than the aggregate of every
> mainframe in the world today.

I suspect the computers behind the Google search engine are more powerful enmassé than all of the installed mainframes world wide over the entire history of mainframes.

Mitch

[toc] | [prev] | [next] | [standalone]

#5686

In article <bcf1faf4a52f566960056617e73589de@msgid.frell.theremailer.net>,
Fritz Wuehler  <fritz@spamexpire-201202.rodent.frell.theremailer.net> wrote:
>Brett Davis <ggtgp@yahoo.com> wrote:
>
>> > SPARC is on the way out for marketing reasons anyway, so whatever the answer
>> > is it is probably academic.
>> 
>> SPARC is in the same boat as the 370 and POWER, mainframe/mini margins
>> will keep SPARC alive for at least 20 years.
>
>I don't believe that and I don't understand what you said about mainframe.
>
>SPARC is not a mainframe processor.

No, but it is the in-house processor of Oracle, who are definitely
aiming for a position where people buying their database (and, in an
ideal-for-Larry-Ellison world, people obliged to buy their database
since some industry-standard system requires an Oracle at the back)
get a better deal if they buy a vertically-integrated SPARC system
from Oracle; this isn't a million miles from the mainframe model, and
I think that's the point Brett is making.

Adverts 'our cluster of weird multi-threaded boxes outperforms our
competitor's more expensive closely-coupled SMP' are not aimed at the
readers of comp.arch.

Tom

[toc] | [prev] | [next] | [standalone]

#5689

Thomas Womack wrote:
> 
> No, but it is the in-house processor of Oracle, who are definitely
> aiming for a position where people buying their database (and, in an
> ideal-for-Larry-Ellison world, people obliged to buy their database
> since some industry-standard system requires an Oracle at the back)
> get a better deal if they buy a vertically-integrated SPARC system
> from Oracle; this isn't a million miles from the mainframe model, and
> I think that's the point Brett is making.

In the long run, can Oracle afford to keep SPARC
at the cutting edge of performance?  Cranking out
a new iteration of the architecture every couple
years ain't cheap.

[toc] | [prev] | [next] | [standalone]

#5690

In article <4F2C4CE8.3447518D@sonic.net>,
Mark Thorson  <nospam@sonic.net> wrote:
>Thomas Womack wrote:
>> 
>> No, but it is the in-house processor of Oracle, who are definitely
>> aiming for a position where people buying their database (and, in an
>> ideal-for-Larry-Ellison world, people obliged to buy their database
>> since some industry-standard system requires an Oracle at the back)
>> get a better deal if they buy a vertically-integrated SPARC system
>> from Oracle; this isn't a million miles from the mainframe model, and
>> I think that's the point Brett is making.
>
>In the long run, can Oracle afford to keep SPARC
>at the cutting edge of performance?  Cranking out
>a new iteration of the architecture every couple
>years ain't cheap.

Oracle isn't short on money; it looks as if they're willing to spend
on R&D roughly what they get in revenue for hardware, to spend on
sales roughly what they get in revenue for new software, and to keep
as profit roughly what they get in revenue for software license
renewals and support contracts.  $700 million a month profit in FY
2011; R&D spending roughly half of Intel's.  I wouldn't bet against
them in the long run, any more than against IBM.

Tom

[toc] | [prev] | [next] | [standalone]

#5692

Thomas Womack wrote:
> 
> Oracle isn't short on money; it looks as if they're willing to spend
> on R&D roughly what they get in revenue for hardware, to spend on
> sales roughly what they get in revenue for new software, and to keep
> as profit roughly what they get in revenue for software license
> renewals and support contracts.  $700 million a month profit in FY
> 2011; R&D spending roughly half of Intel's.  I wouldn't bet against
> them in the long run, any more than against IBM.

I wonder how often Unisys refreshes the
ClearPath MCP architecture, and how big
is the group assigned to that?

[toc] | [prev] | [next] | [standalone]

#6211

Mark Thorson  <nospam@sonic.net> wrote:
>I wonder how often Unisys refreshes the
>ClearPath MCP architecture, and how big
>is the group assigned to that?

As I understand it, Unisys has moved to an emulator running on Intel
processors.

I heard this from someone who took early retirement in the Unisys hardware
group layoffs that resulted from that transition.

[toc] | [prev] | [next] | [standalone]

#5701

Mark Thorson <nospam@sonic.net> writes:
>In the long run, can Oracle afford to keep SPARC
>at the cutting edge of performance?

Better: They can afford to keep SPARC in the backwaters of
performance.  SPARC has never been cutting-edge, and was farther from
it the older it became, yet it has survived architectures that were
closer to the cutting edge (e.g., Alpha).  SPARCs are not bought for
their fast performance, so why spend lots to make them perform fast?

- anton
-- 
M. Anton Ertl                    Some things have to be seen to be believed
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

[toc] | [prev] | [next] | [standalone]

#5711

> In the long run, can Oracle afford to keep SPARC
> at the cutting edge of performance?  Cranking out
> a new iteration of the architecture every couple
> years ain't cheap.

Fujitsu was doing most of the heavy lifting and Larry thought he could play
superman but decided suddenly it wasn't his bag. He does that quite a lot it
seems, before he said the "cloud" was stupid and now Solaris 11 is "the
cloud OS".

[toc] | [prev] | [next] | [standalone]

#5708

Thomas Womack <twomack@chiark.greenend.org.uk> wrote:

> In article <bcf1faf4a52f566960056617e73589de@msgid.frell.theremailer.net>,
> Fritz Wuehler  <fritz@spamexpire-201202.rodent.frell.theremailer.net> wrote:
> >Brett Davis <ggtgp@yahoo.com> wrote:
> >
> >> > SPARC is on the way out for marketing reasons anyway, so whatever the answer
> >> > is it is probably academic.
> >> 
> >> SPARC is in the same boat as the 370 and POWER, mainframe/mini margins
> >> will keep SPARC alive for at least 20 years.
> >
> >I don't believe that and I don't understand what you said about mainframe.
> >
> >SPARC is not a mainframe processor.
> 
> No, but it is the in-house processor of Oracle, who are definitely
> aiming for a position where people buying their database (and, in an
> ideal-for-Larry-Ellison world, people obliged to buy their database
> since some industry-standard system requires an Oracle at the back)
> get a better deal if they buy a vertically-integrated SPARC system
> from Oracle; this isn't a million miles from the mainframe model, and
> I think that's the point Brett is making.

I think your information on SPARC from a /marketing/ point is stale. Larry
did come out swinging claiming he would beat Intel and IBM and everybody
else in the world and run them all out of business. Very soon after that he
killed off more than 75% of existing SPARC boxes by EOLing a huge amount of
servers based on sun4u and earlier. These machines aren't supported in
Solaris 11 even though they were in Solaris 11 Express the day before 11 was
released! That leaves only the late model SPARC machines which are few and
far between and Larry is now selling plenty of Oracle branded Intel servers
and whoever he pissed off is now buying Dell or HP Intel boxes or IBM
POWER. I stand by my prediction. As good as SPARC is and as much as I loathe
Intel, SPARC is dead and Intel is it for the forseeable future. Larry killed
SPARC as much as anyone. Unless he has a rabbit up his sleeve he is as
responsible as anyone for wiping the architecture out of existence.

> 
> Adverts 'our cluster of weird multi-threaded boxes outperforms our
> competitor's more expensive closely-coupled SMP' are not aimed at the
> readers of comp.arch.

Hehe yeah those are quite tiresome aren't they. But they're also not aimed
at mainframes. It's an entirely different business model.

[toc] | [prev] | [next] | [standalone]

#5712

In article <f2406a432e2e4f300faa9a585f0dda9a@dizum.com>,
 Nomen Nescio <nobody@dizum.com> wrote:

> Thomas Womack <twomack@chiark.greenend.org.uk> wrote:
> 
> > In article <bcf1faf4a52f566960056617e73589de@msgid.frell.theremailer.net>,
> > Fritz Wuehler  <fritz@spamexpire-201202.rodent.frell.theremailer.net> wrote:
> > >Brett Davis <ggtgp@yahoo.com> wrote:
> > >
> > >> > SPARC is on the way out for marketing reasons anyway, so whatever the answer
> > >> > is it is probably academic.
> > >> 
> > >> SPARC is in the same boat as the 370 and POWER, mainframe/mini margins
> > >> will keep SPARC alive for at least 20 years.
> > >
> > >I don't believe that and I don't understand what you said about mainframe.
> > >
> > >SPARC is not a mainframe processor.
> > 
> > No, but it is the in-house processor of Oracle, who are definitely
> > aiming for a position where people buying their database (and, in an
> > ideal-for-Larry-Ellison world, people obliged to buy their database
> > since some industry-standard system requires an Oracle at the back)
> > get a better deal if they buy a vertically-integrated SPARC system
> > from Oracle; this isn't a million miles from the mainframe model, and
> > I think that's the point Brett is making.
> 
> I think your information on SPARC from a /marketing/ point is stale. Larry
> did come out swinging claiming he would beat Intel and IBM and everybody
> else in the world and run them all out of business. Very soon after that he
> killed off more than 75% of existing SPARC boxes by EOLing a huge amount of
> servers based on sun4u and earlier. 

Sun4u looks to be ancient dual core UltraSPARC's of unknown to wiki version.
http://en.wikipedia.org/wiki/Sun-4
http://en.wikipedia.org/wiki/Sparc

~half decade old boxes, desktop riffraff Oracle wants gone?

These are chump change to Oracle that are just costing money in support.
The money is in the big iron.
Dumping the riffraff changes perceptions of what SPARC is, now uber server,
not obsolete expensive proprietary UNIX desktop replaced by Linux.

[toc] | [prev] | [next] | [standalone]

#5758

On Feb 3, 10:19 am, Fritz Wuehler
<fr...@spamexpire-201202.rodent.frell.theremailer.net> wrote:

> I don't believe that and I don't understand what you said about mainframe.
>
> SPARC is not a mainframe processor.

This is true. But ORACLE bought Sun, it appears to me, specifically to
have its own hardware architecture for database machines - with the
intention of competing head-to-head with IBM. So even though SPARC had
not been a mainframe architecture in the past, it is likely to become
one. SPARC chips do, unlike most x86 chips, have RAS features.

John Savard

[toc] | [prev] | [next] | [standalone]

#5691

In article <ggtgp-A1F9BB.02163102022012@netnews.mchsi.com>,
Brett Davis  <ggtgp@yahoo.com> wrote:
>Are rotating register files still a bad idea?

I never thought that they're a bad idea.  At best we can say that
they're not obviously worse or better.

It does seem cool, but leaving save and restore to the compiler seems to
work just as well.  Compilers now are good at that.

I doubt it has much damage in clock speed.  Of course they require
transistors to implement.  Arguably we can save cache because there's
less movement to/from the stack, plus the instructions to do that.

Alternative is a 'stack cache'.  Along with that, we can have nn(%sp)
shorter than others (to some extent, we do, with push and pop opcodes).

[toc] | [prev] | [next] | [standalone]

#5697

On 2/2/2012 12:16 AM, Brett Davis wrote:
> Are rotating register files still a bad idea?
>
> Rotating register files used to mean slow clock speeds.
> SPARC has had competitive clocks for the past decade,
> largely because everyone hit a thermal brick wall...
>
> I assume that if that brink wall breaks, rotating register files
> are back to being doomed, but that looks unlikely.
>
> Does rotating register files buy you anything net after costs,
> or is it just a fiasco in the age of modern OoO pipelines?



When I first saw your post, I thought that you were talking about the 
rotating register file that Cydrome and Itanium had, that could be made 
to rotate on every loop iteration, and not SPARC-style overlapping 
register windows (which Itanium also had).

I actually think that Cydrome state rotating register files may be a 
good idea, albeit neglected.  They allow software pipelining to be done 
without requiring reg-reg moves and give many of the benefits of loop 
unrolling without increasing code size.

Overlapping register windows for function calls I am not so sure about.

One thing the think about:  GPU style multiple threads in the same 
register file.

a) COULD work with rotating register windows for loops

b) would be much harder to make work with overlapping register windows 
for function calls.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.arch

csiph-web