Re: [Fwd: Re: SH5 compact register numbering in gcc -> gdb interface]

[Andrew Cagney <ac131313@cygnus.com>]

> Let me get this straight.
> You want a unified simulator interface, not reusing register numbers
> for registers with different sizes  Since the SH1..SH4 numbers
> are already assigned for a bunch of 32 bit registers, the SH5
> simulator register numbers will have to start after the SH4 ones,
> i.e. the register numbers for the SH5 simulator have to be sparse
> (have a large gap at the start).

The reason I recommended doing something to the simulator register 
numbers was to detect problems when combining SH* gdb with a simulator 
in a specific mode.

For instance, given a SIM modeling the SH4 ISA, it doesn't make sense 
for GDB to try to read SH5 hardware registers - the SIM doesn't have 
them.  By assigning different sim_regnum's to each ISA, GDB/SIM can 
detect a conflict.

There are other ways of handling this, I happen to think that this is 
the simplest.

> Now you are saying that the remote protocol does not allow to start
> the registers with a number other than zero, and the register numbers
> should not be sparse.

This isn't new.  For a given ISA [0..NUM_REGS) are hardware/raw 
registers.  Pseudo-registers can't be put before this.  Making the 
number of registers sparse means having to iterate over gaps.

> Thus, by unifing the register numbering in the SH1-4 / SH5 simulator
> interface, we must make the register numbering SH5 simulator interface
> different from the one in the SH5 remote interface.

Yes.  For GDB, having to do this is just another fact of life :-)

> It appears to me that we make the entire mess even harder to maintain
> this way.  Why is having different register numbering for the same
> processor for simulator / remote better than having different numbering
> between the SH1..SH4 simulator vs. the SH5 simulator?

Remember, GDB has a number of interfaces (sim, remote, dwarf2, stabs, 
mdebug, ptrace, ....) and (except for the remote protocol) each will 
have its own register numbering scheme.  While trying to make all 
numbering schemes identical sounds good in theory it turns out to be 
impossible in reality.  Hence, I think, pinning down specific interfaces 
is more important than trying to go for a single unified numbering scheme.

Once remote.c has been ``fixed'' it will be possible to improve things 
though.

enjoy,
Andrew