Newsgroups: comp.arch

In comp.arch, desj@ccr-p.ida.org (David desJardins) writes:

> None of John's reasons (except for putting integer and fp registers on
> separate chips) seem to explain why the instruction set should not at
> least allow transfers between the integer and fp registers.  After all,
> I as a user am paying in gates and chip space for those registers.  Why
> shouldn't I be able to use them at least as fast temporary storage, for
> register spilling and the like?

This is a very reasonable question.  I think I may be able to at least
partially answer it.

Of course if your architecture was designed when floating point was on
a seperate chip, then there was not much incentive to include a
register transfer instruction.  So I think this is one feature that
you might start seeing in revisions of the older architectures.
However there is still a trade-off to be made, and that may be why
Alpha left it out, and why it may be slow in coming to the older
ISA's.

To get the data from one register set to the other you either have to
add read/write ports, a bus and corresponding control logic, or you
have to cleverly use the existing read/write ports and busses, at some
cost in control complexity.  The performance you gain depends on how
efficiently you can do the transfer and how fast you could have done
it without adding any special hardware or instructions.

For example without a transfer instruction you might do a store and a
load from cache to do the transfer.  Suppose this takes 3 cycles.  If
you add new register ports and a new bus you can almost certainly do
the new transfer instruction in one cycle.  So your trade-off is 2
cycles times "how common are register transfers" versus a rather
significant hardware cost (as John pointed out, register read/write
ports are precious).

Suppose you instead try to use existing busses and register ports.
Suppose your data bus goes to both register sets so you decide to use
the ports that exist for loads and stores.  Now you can make your
fp-to-int transfer "look like" a store to the fp registers and "look
like" a load to the integer registers.  Unfortunately there's a good
chance that loads and stores access the registers in different
pipeline stages.  So you've got two choices.

1.  You can add the control complexity so that the load/store ports
operate in different pipeline stages depending on whether you're doing
a transfer or a real load/store.  There may be electrical/speed issues
here if you use the same bus for loads and stores, because you may
have to change bus directions more frequently.  But if you can get
around all that and can accept the control complexity you can probably
do your transfer in 1 cycle.

2.  You can add cycles of latency to the transfer instruction so that
it still "looks like" a load to one register set and a store from the
other.  This is simpler to implement but still takes some control
complexity and buys you less performance since your transfer might now
take 2 cycles.

So there's a real trade-off involved and, depending on how common/important
they think register transfers are, I can understand designers going either
way on this issue.

	Will Walker
	wlw@fc.hp.com
	my own opinions
Newsgroups: comp.arch