shared register file

Potatoswatter (potswa_m@c.com) on 8/7/08 wrote:
---------------------------
>Michael S (already5chosen@yahoo.com) on 8/7/08 wrote:
>---------------------------
>>Disclaimer:
>>The discussion below is purely theoretical and not related to Power7. After very
>>brief observation of the info provided in this thread I tend to agree with Potatoswatter:
>>Power7 architecture merges VPR and FPRs but retains traditional separation between GPRs and the rest.
>>
>>
>>RagingDragon (a@b.c) on 8/6/08 wrote:
>>---------------------------
>>>Anil Maliyekkel (a@a.edu) on 8/6/08 wrote:
>>>---------------------------
>>>>
>>>>They alias with the entire 128 bit VSX register.
>>>
>>>Does that mean the CPU would have one large register file, shared by integer, floating
>>>point, and vector execution units? If so that would be an extremely unconventional
>>>design - has anyone ever made a CPU like that?
>>>
>>
>>At uArch layer that's exactly what Intel is doing in PM and Merom. Possibly, P6 too but I'm not 100% sure.
>>
>>At software-visible architecture layer you can look, for example, at Freescale
>>e500 and possibly other E-Book compliant PPC cores. I am sure, that there were multiple historic predecessors
>>
>>>What would be the benefit of a shared register file? I guess it would be sacrificing
>>>ILP to increase TLP - i.e. allow more cores (fewer transistors, less power, per
>>>core) at the expense of reducing the number instructions executed per cycle by each
>>>core due increased register contention.
>>
>>It depends. I don't see that Merom sacrifices any ILP relatively to, for example,
>>K8/K10 that feature split register files.
>>Of course, Merom shares physical registers rather than architected, but the # of
>>architected registers in Power7 is similar to # of physical registers in Merom (IRCC, 72).
>>
>>>It would also facilitate sharing logic transistors
>>>between integer and integer vector, and floating point and floating point vector
>>>too - another way to increase TLP at the expense of ILP.
>>
>>IMHO, for wide in-order cores the biggest disadvantage is increased fan-out.
>>For less-wide cores, both 'in' and 'out of' order, there is a problem of crowded
>>silicon area around register file, that, in high-frequency design, would lead to
>>pushing FPU further away from registers and possibly to addition of stage in FPU pipeline.
>>
>>For lean cores, neither wide nor hi-freq, I see no disadvantage at all.
>
>Wow, I had no idea about that. I suppose it makes sense, and clears up some confusion
>I had about Intel's block diagrams.
>
>So what you're saying is, Merom and successors store a pair of 64-bit regs in a
>physical 128-bit reg, or else vice versa.


No, not all.
They store a 64-bit GP register in the lower part of 128-bit register (or, may be, physical registers are 144-bit wide, I'm not sure). The upper part is unused.
Similarly, in PM they store 32-bit GP registers and 64-bit half-SSE registers in the lower part of 80-bit physical registers.

>Constantly muxing 128=>64 sounds like
>a pain, so it seems more practical to synthesize vector ops from 2x64bit reg pairs.
>But, doubling the number of functional units in the datapath is physically tougher
>than twice as wide and equal length...
>
>Also, reservation and writeback seem to need a lot more entries. Is there any evidence
>of resource contention between scalar and SSE?
>
>It's wacky that Intel would make this kind of change and still call the result "P6." Not that I doubt it, but wacky.