Re: [WIP/RFC] MIPS registers overhaul

[cgd at broadcom dot 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.