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 13:05:59 -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> <3EECAB89.10609@redhat.com>
It's unfair to make me think really hard after being gone for almost a
week. I've had to resort to experimental analysis. 8-)
It would be good, BTW, to reference against the MIPS32 or MIPS64
specs; I dunno that everybody in the world has a MIPS IV spec, and
certainly I might but if i do it's not as handy.
At Sun, 15 Jun 2003 13:23:21 -0400, Andrew Cagney wrote:
> >> For instance, do a 64 bit FP restore then clear the FR bit; the
> >> reverse; some other variant; ...?
> > So, if the process is running with FR=0, then the save/restore should
> > ("must" i believe) be done with FR=0.
> > When FR=0, there are two options as to how to do it:
> > for (i = 0; i < 32; i++)
> > move/store word from c1 reg $i (i.e., dmfc1/sdc1)
>
> mfc1/sc1
yah.
> > OR:
> > for (i = 0; i < 32; i += 2)
> > move/store dword from c1 reg $i (i.e., dmfc1/sdc1)
>
> OK, I'm going to go out on a limb here. I don't think the two are
> equivalent, and I think the second is wrong. For big-endian, the
> second would store fp[n+0] ||| fp[n+1] backwards.
No, the two are not equivalent, in terms of the memory layout that
results on big endian systems. (On little-endian systems, AFAICT they
end up producing the same results.)
However, neither is more correct w.r.t. what's allowed by the MIPS
architecture; both will work with MIPS2 and later hardware. Doing the
stores as dwords is clearly more efficient, though.
> When extracting a double from a MIPS register pair, GDB does the rough
> equivalent of:
>
> [...]
>
> (See register_to_type. The code dates back to ~92 and was added to
> fix IRIX double value display problems.) The effect is to always get
> the least significant part of a double value from fp[n+0], and the
> most significant from fp[n+1].
Err, I'm not sure what code you reference. I couldn't find
"register_to_type" (case insensitively), anywhere in the GDB source.
I do note that the code in mips-tdep.c:
static void
mips_read_fp_register_single (struct frame_info *frame, int regno,
char *rare_buffer)
static void
mips_read_fp_register_double (struct frame_info *frame, int regno,
char *rare_buffer)
but i'm not sure whether your pseudo-code above is meant to convey the
operation of the latter, and, if so for 8-byte FPRs (with the mips2
compat thing), or 4 byte FPRs... (8 byte FPRs with mips2 compat looks
... scary. 8-)
> Given MIPS xor endian sillyness,
I'm not quite sure which silliness you mean.
The "ReverseEndian" xoring (in the pseudo-code) happens only if
Status:RE is set. I'll admit that the 'bytesel' logic in the sw/swc1
ops takes a while to understand. 8-)
Normally (when RE is not set) it behaves in (IMO) a sane enough way...
> Anyway, this, I believe, means that any implementation of:
>
> union {
> float flt;
> double dbl;
> int32 i32;
> int64 i64;
> } $fp0
>
> is going to need, for BE, a big-byte little-word DOUBLE, and a similar
> INT64. Otherwize, $f0.int32 would modify the wrong part of the double
> register. Alternatively, some of those union values could be given
> magic offsets. Looking at kevin's patch:
Right. I think the "assume 4 bytes of pad before the 4-byte item" is
the right way to look at it.
And then to follow on from that:
* if 32-bit FPU (32-bit MIPS or 64-bit MIPS with FR == 0), assume you
have 16 of them, or
* if 64-bit FPU, you have 32.
(at least, that's the way it should work for "normal" FPU usage. For
single-float, where $f0 and $f1 contain independent singles, it's
another story.)
Re: your other message, re: the kernel shifting them around:
I *think* that the linux kernel does shift things around as
appropriate, at least for the r4k-and-later chips. (TBH, I'm not sure
that it's correct for the r2k/r3k.)
It's been so long that i forgot what the issue at the root of this
disucssion was. Could you remind me? 8-)
cgd
--
Chris Demetriou Broadcom Corporation
Principal Design Engineer Broadband Processor Business Unit
Any opinions expressed in this message are mine, not necessarily Broadcom's.