Re: [WIP/RFC] MIPS registers overhaul

cgd
2003-06-16T20:06:07Z

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.