[RFA] MIPS: Introduce struct mips_regnums and accessors

Andrew Cagney ac131313@redhat.com
Thu May 22 19:41:00 GMT 2003


> 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.  */
>> > +  };
> 
> 




More information about the Gdb-patches mailing list