shared register file

Linus Torvalds (torvalds@linux-foundation.org) on 8/7/08 wrote:
---------------------------
>Potatoswatter (potswa_m@c.com) on 8/7/08 wrote:
>>
>>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.
>
>You're trying much too hard to pack things tightly, for
>no reason.
>
>No, you'd never try to store a pair of 64-bit registers
>in a 128-bit reg (well, "never" is obviously not true:
>it is how some people do extended doubles). The much
>simpler approach is to just have 128 bits per register,
>and if that's more than you need, who cares? The integer
>ops would only use the mantissa bits.
>
>The advantage is that you can share all the paths to the
>register file - which can be important since there are a
>number of ops that actually do mix integer and FP
>values.
>
>The most trivial example is sharing the divider(s), but
>there are actually instructions to move from one "type"
>of register to another (ie "movd"/"movq" to move from an
>integer register to a XMM register in x86).
>
>And if you want to do that with zero latencies (ie doing
>it as a register rename rather than any actual physical data
>movement between register files), then you need to have a
>unified register file.
>
>Note that historically, floating point and integer
>were a lot more separate than they are today. It used to be
>uncommon to have to convert from one to another. But the
>FP units have been turned into vector units and often work
>on integer or fixed-point data, and the separation of FP
>and integer isn't nearly as clear as it used to be.

My impression is that there's a 1 cycle latency for any communication between int and fp reg files for Merom & Co....is that incorrect?

DLK