Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdcad!mozart.amd.com!nucleus!davec
From: davec@nucleus.amd.com (Dave Christie)
Newsgroups: comp.arch
Subject: Re: taxonomy for superscalars/etc (RS/6000 example)
Message-ID: <1990Jul25.172053.27085@mozart.amd.com>
Date: 25 Jul 90 17:20:53 GMT
References: <9782@hubcap.clemson.edu> <1990Jul23.182546.25777@mozart.amd.com> <37240@shemp.CS.UCLA.EDU>
Sender: usenet@mozart.amd.com (Usenet News)
Reply-To: davec@nucleus.amd.com (Dave Christie)
Organization: Advanced Micro Devices, Inc., Austin, Texas
Lines: 25

In article <37240@shemp.CS.UCLA.EDU> marc@oahu.cs.ucla.edu (Marc Tremblay) writes:
>
>In the current version of the RS6000, floating point arithmetic instructions
>are executed in sequence. There is thus no need to assign new tags to the
>destination registers of these instructions. Only the floating point loads
>create a new assignment in the mapping table (logical to physical translation
>table). So the real purpose of the register renaming scheme in the RS/6000
>is to be able to process floating point loads without waiting for source
>registers to be used by previous instructions.
>

Is the remapping permanent? Or are the load operands eventually 
transferred into physical registers as designated in the instruction?  
If it's permanent, then this _looks_ less like a queue, but the overall
effect is the same.

Permanent remapping would imply that all FP operand references would
have to go through the mapping table, slowing down access a tad.  I've
seen the register set described as "32 Floating Point registers and
six rename registers", but that really doesn't indicate whether it's a
pool of 38 logically-addressed registers, or 32 physically addressed
registers + a queue :-) of 6 load operand registers.

----------------------
Dave Christie        My opinions only.