Re: [WIP/RFC] MIPS registers overhaul

[cgd@broadcom.com]

At Sat, 14 Jun 2003 21:36:04 -0400, Andrew Cagney wrote:
> Chris?

Sorry, I must have missed that msg...  8-)


> That isn't quite the detail I was looking for.  Does the code need to 
> look like:
> 
> save::
> 	save FSR
> 	if (FSR & FR)
   *** when FR == 1, it's 32 64-bit registers.  so, invert.
> 	  save 32x32 FP
   *** or, save 16 (even) 64-bit FP registers, if MIPS2 or later.
   *** in fact, on MIPS2 and later, better to do that, since it'll be
   *** more efficient (fewer instructions).
> 	else
> 	  save 32x64 FP
> 
> restore::
> 	restore FSR
> 	if (FSR & FR)
> 	  restore 32x32 FP
> 	else
> 	  restore 32x64 FP
> 
> that is, the FSR[FR] bit (wonder if I've got the names right) needs to 
> set/clear the FR bit before it even starts to consider saving/restoring 
> the other registers.

It's Status:FR (or, SR:FR, but i prefer to call the regs by their
proper names 8-).  (also, "or, use notation of your choice."  8-)

(it's in the normal CP0 status register, not in any of the FPU control
registers.  all of the latter are user-accessable, but Status:FR is
not.)


> The reverse operation:
> 
> save::
> 	save FSR
> 	make FP registers 64 bit
> 	save 32x64 FP
> 
> restore::
> 	// assume FSR[FR] set to 64 bit mode
> 	restore 32x64 FP
> 	restore FSR
> 
> operation not being valid.

So, I looked at the specifications, and I don't couldn't find any
place where this is defined by the current architecture to be
UNPREDICTABLE, but i may have missed it.

I would expect -- but haven't checked -- that this would work as well.
Looking at the diagrams in the MIPS32 and MIPS64 specs which try to
explain opration behaviour w/ the various FR modes, I think i'd
*expect* it to work.

Based on the diagrams in the manuals, I'd *expect* that if you do
this, the even registers would contain all of the data used in FR=0
mode, and the odd registers would contain... whatever they were
initialized with when FR was set to 0 initially.

Personally, I wouldn't do this.  8-)


Note also that some processors do have ... interesting hazards when
changing Status:FR modes, too.  If one can keep the number of FR mode
changes to a minimum one can also reduce the number of
hazard-avoidance sequences needed.  In the former example, you do one
Status:FR set per save/restore.  In the latter, you do two.


cgd
--
Chris Demetriou                                            Broadcom Corporation
Principal Design Engineer                     Broadband Processor Business Unit
  Any opinions expressed in this message are mine, not necessarily Broadcom's.