This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [WIP/RFC] MIPS registers overhaul
- From: cgd at broadcom dot com
- To: "Andrew Cagney" <ac131313 at redhat dot com>
- Cc: "Kevin Buettner" <kevinb at redhat dot com>,gdb-patches at sources dot redhat dot com
- Date: 16 Jun 2003 11:06:09 -0700
- Subject: Re: [WIP/RFC] MIPS registers overhaul
- References: <1030510002453.ZM3880@localhost.localdomain><3EBD6131.30209@redhat.com><1030514220025.ZM10373@localhost.localdomain><3EC461C1.1080104@redhat.com> <mailpost.1053057614.17325@news-sj1-1><yov5znlma5s9.fsf@broadcom.com> <mailpost.1053123913.16634@news-sj1-1><yov5wugqa4m8.fsf@broadcom.com> <3ECA8EC6.6030405@redhat.com><yov5llx1mkab.fsf@broadcom.com> <3ECB9DE2.1020906@redhat.com><3EEBCD84.6010005@redhat.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.