Re: [RFA] New register definition interface

[Andrew Cagney <ac131313 at cygnus dot com>]

Nick Duffek wrote:
> 
> On 14-Jan-2001, Andrew Cagney wrote:
> 
> >BTW, Is there a working example of this code at work?
> 
> Yes, but not that I can publish at the moment.
> 
> >The PowerPC perhaphs?
> 
> I've been considering that.  The various PPC chips have varied register
> sets that this interface should handle nicely.

It is much easier to justify the acceptance of your changes if there is
a real live working example.  Especially one that demonstrates how easy
(?) it is to update an existing target.

At present there is no reason to hurry with the change.

Could I strongly encourage you to do this in two separate steps:

	o	sort out the cli/cli* stuff so that
		it is independant of regs.c

		demonstrate this

	o	then sort out regs.c

I know this is more onerous on your part, however, I can see significant
long term benefits in sorting out cliregs so that it is independant of
regs.c.  To put it another way, if that work isn't done, then I suspect
that, apart from the new obscure ports comming out of Red Hat, your work
will just sit on a shelf gathering dust :-(.  I'll try to explain why
I'm somewhat negative.

Both MI and Insight (GDBtk) have been screaming out for a mechanism that
added formatting information to the register description.  I think your
cliregs code provides a proof-of-concept of this.

Unfortunatly, cliregs assumes your custom regs.c when obtaining that
information.  That in turn means that for an existing target to provide
those annotations it must completly re-implement its register interface
(and as they say in the clasics, if it ain't broke, don't fix it :-( ). 
Simiarly, for MI and Insight, this new annotation information might look
useful, however, since it is only provided by a few new and obscure
targets that use a custom regs.c there is no real incentive to exploit
it.

If instead, published interfaces (based around GDBARCH and REGNUM) were
created and cliregs used those then I'd expect both MI and Insight to
also quickly adopt them - they wouldn't be reliant on a custom regs.c. 
Similarly, since only an incremental change to the target - add the new
methods - would be needed, it would be very easily to tweek existing
targets so that they too could benefit from this code.

	Andrew