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