From: Andrew Cagney <ac131313@redhat.com>
To: Kevin Buettner <kevinb@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] MIPS: Introduce struct mips_regnums and accessors
Date: Thu, 22 May 2003 19:41:00 -0000 [thread overview]
Message-ID: <3ECD27B0.1060906@redhat.com> (raw)
In-Reply-To: <1030521204035.ZM32420@localhost.localdomain>
> On May 21, 3:38pm, Andrew Cagney wrote:
>
>
>> I think the struct contains too many redudnant fields.
>
>
> Redundant? In what way?
>
>
>> Instead it can
>> be be trimmed back to identify just the boundaries between the different
>> register groups vis:
>>
>> - gp0 (gp31?)
>> - fp0
>> - hi, lo
>> - pc
>> - various status registers
>> - others?
>
>
> With the exception of fplast (which I added), the member names are
> identical to the macro names used in tm-mips.h. I did this to make
> it easier to convert *_REGNUM to using the struct members.
>
>
>> As for assigning meaning to specific registers (v0, a0, ...) within a
>> group, offsets can be used vis:
>>
>> v0_regnum (regnums) === regnums->gp0 + offset;
>
>
> This makes it much more difficult to do an obvious conversion from
> (e.g.) V0_REGNUM to rawnums->v0_regnum. Also, do you really think
> it's preferable to have to say:
>
> regnums->gp0 + regnumoffsets->v0_offset
>
> instead of
>
> regnums->v0_regnum
>
> ?
Sorry, I'm lost. The patch contains:
+ /* Raw register number initializations. They are initialized in the
+ same order that they appear in the struct to make it easier to
+ verify that they're all initialized. */
+ tdep->raw_regnums.zero_regnum = 0;
+ tdep->raw_regnums.v0_regnum = 2;
+ tdep->raw_regnums.a0_regnum = 4;
+ tdep->raw_regnums.t9_regnum = 25;
+ tdep->raw_regnums.sp_regnum = 29;
+ tdep->raw_regnums.ra_regnum = 31;
and, at least for v0_regnum, it doesn't change. V0 is an offset in the
selected block of registers. It could be either:
enum { V0_OFFSET = 2 };
cookednum->gp0 + V0_OFFSET
or
rawnum->gp0 + V0_OFFSET
however, either way, it doesn't change. The only thing that changes is
things like where the general purpose, for floating point, registers start.
Andrew
> I like the last one better due to it's being more concise. The
> initialization may be a little bit harder, but using them will be
> easier and more error free. E.g, with the style you advocate, it's
> possible to say ``regnums->fp0 + regnumoffsets->v0_offset'', but
> that was very likely an error on the part of the author.
>
> Anyway, I am firmly against the offset idea.
>
> I _do_ think, however, it would be useful to have gp0_regnum
> and gplast_regnum members at some point. I considered adding them,
> but decided against it on the grounds that the first step to
> converting from _REGNUM to rawnums->_regnum should be as obvious
> and straightforward as possible.
>
>
>> With regard to having only 16 o32 FP registers, is that right?
>
>
> I think so, yes. I've been told that for o32 you only really have
> 16 FP registers.
>
>
>> Does it just confuse things? Doesn't the o32 debug info assume a bank of 32
>> contigious 32 bit registers?
>
>
> As I understand it, the odd register numbers are never used.
>
> I have the {stab,ecoff,dwarf,dwarf2}_reg_to_regnum functions convert to
> the appropriate cooked numbers.
>
> I think things will end up being much more confused if you somehow
> throw the odd registers into the mix. Consider iterating over the set
> of cooked floating point registers. If we throw the odd numbered
> registers in somehow, we'll have to arrange to skip them in most
> circumstances.
>
> Also, if we do throw in the odd registers, what should their types
> be?
>
>
>> A location expression for a double in
>> ``f0'' would be f0:f1 for instance.
>
>
> I don't think that's the representation. I.e, you only see the f0, not
> the f1. I can arrange for a warning or error for odd registers if you
> like.
>
>
>> > +/* MIPS register numbers. */
>> > +struct mips_regnums
>> > + {
>> > + int zero_regnum; /* The zero register; read-only, always 0. */
>> > + int v0_regnum; /* Function return value. */
>> > + int a0_regnum; /* First GPR used for passing arguments. */
>> > + int t9_regnum; /* Contains address of callee in PIC code. */
>> > + int sp_regnum; /* Stack pointer. */
>> > + int ra_regnum; /* Return address. */
>> > + int ps_regnum; /* Processor status. */
>> > + int hi_regnum; /* High portion of internal multiply/divide
>> > + register. */
>> > + int lo_regnum; /* Low portion of internal multiply/divide
>> > + register. */
>> > + int badvaddr_regnum; /* Address associated with
>> > + addressing exception. */
>> > + int cause_regnum; /* Describes last exception. */
>> > + int pc_regnum; /* Program counter. */
>> > + int fcrcs_regnum; /* FP control/status. */
>> > + int fcrir_regnum; /* FP implementation/revision. */
>> > + int fp0_regnum; /* First floating point register. */
>> > + int fplast_regnum; /* Last floating point register. */
>> > + int fpa0_regnum; /* First floating point register used for
>> > + passing floating point arguments. */
>> > + int first_embed_regnum; /* First CP0 register for embedded use. */
>> > + int last_embed_regnum; /* Last CP0 register for embedded use. */
>> > + int prid_regnum; /* Processor ID. */
>> > +
>> > + int last_arg_regnum; /* Last general purpose register used for
>> > + passing arguments. (a0_regnum is the
>> > + first.) */
>> > + int last_fp_arg_regnum; /* Last floating point register used for
>> > + passing floating point arguments. */
>> > + };
>
>
next prev parent reply other threads:[~2003-05-22 19:41 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-05-15 23:51 Kevin Buettner
2003-05-21 19:39 ` Andrew Cagney
2003-05-21 20:40 ` Kevin Buettner
2003-05-22 19:41 ` Andrew Cagney [this message]
2003-05-22 20:16 ` Kevin Buettner
2003-06-15 18:37 ` Andrew Cagney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3ECD27B0.1060906@redhat.com \
--to=ac131313@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kevinb@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox