Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucla-cs!oahu.cs.ucla.edu!marc
From: marc@oahu.cs.ucla.edu (Marc Tremblay)
Newsgroups: comp.arch
Subject: Re: taxonomy for superscalars/etc (RS/6000 example)
Message-ID: <37269@shemp.CS.UCLA.EDU>
Date: 25 Jul 90 19:59:31 GMT
References: <1990Jul23.182546.25777@mozart.amd.com> <37240@shemp.CS.UCLA.EDU> <1990Jul25.172053.27085@mozart.amd.com>
Sender: news@CS.UCLA.EDU
Organization: UCLA Computer Science Department
Lines: 55

In article <1990Jul25.172053.27085@mozart.amd.com> (Dave Christie) writes:
>In article <37240@shemp.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.

The remapping is permanent ... until of course the same logical register
gets reassigned to another physical register. All subsequent instructions
access the logical tag through the map table so that they access the latest
physical tag assigned.

>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.

There isn't a separate pool of registers assigned to be "rename registers".
All physical registers can be used for renaming.
During normal execution the 40 tags (some IBM literature says 38 tags)
are distributed as follow:

	1) 32 logical tags are assigned to 32 physical registers.
	2) a number of tags n (0<n<8) are stored in the Free List
	   ready to be used for new assignments.
	3) a number of tags (8-n) are waiting to be released by floating
	   arithmetic instructions or floating-point stores so that
	   they can be sent to the Free List for ulterior assignments.

A full cycle seems to be allocated for register renaming. That's plenty
of time to access the map table and manage the tag lists. I suspect that
they may even do it twice per cycle to reduce the number of ports
of the map table. Indeed if two instructions can be renamed per cycle,
and if both are FMA (Fused multiply and add) which require 3 source
tags and one destination tag, that's 8 ports/cycle for the mapping table.

An extra stage in the pipeline can be a limiting factor but in this case
it does not affect the pipeline result latency among adjacent instructions.
It does affect though the waiting time for example for a conditional
branch waiting for a floating-point compare. But that's a pretty rare case.

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