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

Groups > comp.arch > #1495 > unrolled thread

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

Back to article view | Back to comp.arch

Contents

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

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

On Thursday, May 12, 2011 12:06:59 AM UTC-4, Brett Davis wrote:
[snip]
> Intel does fine with just 2 read ports on the register file,
> most of the values for 4 way execution come from the forwarding
> network. 

It also helps that many instructions use immediates.  Also
splitting stores into two uops helps.  If one has operand 
capture, one would also require fewer read ports.  (I admit 
two read ports seems a bit low for four-wide.)

> For dependent ops you have to do this as registers are too far away?

It seems that the EV8 used a register cache rather than a 
traditional forwarding network.

> Which high end CPU archs actually fully port out their register file?

Itanium is one example.  (I would not be surprised if 
at least some of the POWER uarchs used full RF porting, 
but I do not remember reading about such--and the POWER7 
microarchitecture paper is behind a paywall.)

> (Bear in mind that two years ago I thought Intel fully ported
> their register file. Once I read the paper on how Intel CPUs
> work I assumed all high end CPUs worked this way.)

I think at least some of the earlier Intel x86 used operand 
capture, in which case forwarding of a result does not have 
to be correspond to immediate issue of the dependent 
operation.  The associated reading of operands at entry to 
issue queue could also provide more flexibility in scheduling 
reads than read operands after scheduling.

[toc] | [next] | [standalone]

#1516

On 5/12/2011 8:19 AM, Paul A. Clayton wrote:
> On Thursday, May 12, 2011 12:06:59 AM UTC-4, Brett Davis wrote:
> [snip]
>> Intel does fine with just 2 read ports on the register file,
>> most of the values for 4 way execution come from the forwarding
>> network.

P6 had just 2 read ports on the PRF=ROB+RRRF.  Wmt had full porting.
Nhm had underporting, but I can't say how many ports.

Does Sandybridge still have only 2 ports?

> 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.


>> Which high end CPU archs actually fully port out their register file?
>
> Itanium is one example.  (I would not be surprised if
> at least some of the POWER uarchs used full RF porting,
> but I do not remember reading about such--and the POWER7
> microarchitecture paper is behind a paywall.)

Amusing anecdote: a guy I mentored at AMD told me that he thought that 
he had invented non-fully-ported register files at Sun.  Even though we 
had used them on P6 at Intel (Dave Papworth's great idea), and it was in 
the baseline K10 uarch at AMD.

> I think at least some of the earlier Intel x86 used operand
> capture, in which case forwarding of a result does not have
> to be correspond to immediate issue of the dependent
> operation.  The associated reading of operands at entry to
> issue queue could also provide more flexibility in scheduling
> reads than read operands after scheduling.

The term "operand capture" is a term I invented to describe the P6 CAM 
based RS.  But it also generalizes to non-CAM based OC (Operand Capture) 
mechanisms.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.arch

csiph-web