Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!orion.oac.uci.edu!ucivax!ucla-cs!oahu.cs.ucla.edu!marc
From: marc@oahu.cs.ucla.edu (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: RS/6000 renaming
Message-ID: <37319@shemp.CS.UCLA.EDU>
Date: 26 Jul 90 23:40:51 GMT
References: <1990Jul26.160540.15289@mozart.amd.com> <9871@hubcap.clemson.edu> <2965@zipeecs.umich.edu>
Sender: news@CS.UCLA.EDU
Organization: UCLA Computer Science Department
Lines: 33

>billms@caen.engin.umich.edu (Bill Mangione-Smith) writes:
>> mark@hubcap.clemson.edu (Mark Smotherman) writes:
>>From davec@nucleus.amd.com (Dave Christie):
>>> 
>>> Are you implying that two FP instructions can be issued in one cycle?!
>>> I don't believe this is the case.
>>
>>Yes, the instruction dispatch on RS/6000 does not require a matched
>>pair of an integer instruction and a flt.pt. instruction in order to
>>dispatch (issue?) 
>
>Nope, this is not quite true.  One FP instruction can be issued by the 
>FPU each clock, though it can be a mult-add.  Two can be sent (i.e. dispatched)
>to the FPU each clock, but atleast one of them sits there in a queue.  This
>removes one more worry from the compiler about matching up instructions
>for dispatching from the I cache unit.

The original discussion was on register renaming.
Yes,the RS/6000 can *rename* two instructions per cycle.
Yes,the RS/6000 can execute some combinations of two FP instructions in 1 cycle.
For example a floating-point load and a floating-point mult-add can be executed
in parallel (the fixed-point unit does most of the work anyway!).
If we talk about floating-point arithmetic instructions, no, the RS/6000
cannot execute two of them per cycle (most of them can be pipelined though).

Since the FPU can rename more instructions than it can execute, a buffer
must be inserted between the rename logic and the execution logic.
That's accomplished by the decode buffer.

_________________________________________________
Marc Tremblay
internet: marc@CS.UCLA.EDU
UUCP: ...!{uunet,ucbvax,rutgers}!cs.ucla.edu!marc