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

Joern Rennecke
2002-05-09T13:16:04Z

ac131313@cygnus.com wrote:
>
> > Sorry, I forgot to copy this to the list.
> >
> Any way, with what ever is proposed, just remember that remote.c, the
> remote protocol, and random other bits of GDB currently interact in
> pretty nasty ways. The code very much assumes that GDB's internal
> numbers correspond to the remote protocol numbers; and the remote
> register packet register offsets correspond to GDB's internal register
> buffer offsets [ulgh].
>
> The [unfortunate] consequence is that the first [0..NUM_REGS) of the GDB
> internal registers need to:
> - be hard/raw registers i.e. SH5media
> - occure first in the register buffer
> - the numbers shouldn't be sparse
> After the hard/raw registers come the pseudo-registers (such as
> SH5compact registers). Those registers are not transfered via the
> remote protocol.

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).

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.

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.

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?
--
--------------------------
SuperH
2430 Aztec West / Almondsbury / BRISTOL / BS32 4AQ
T:+44 1454 462330