Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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.  */
>> > +  };
> 
> 



  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