Re: A better register interface

[Andrew Cagney <ac131313@cygnus.com>]

> If I understand you correctly, we would also need a target interface to
> tell the register cache how to map between RAWNUM and cooked REGNUM.  For
> example:
> 
>   /* Associate raw register number RAWNUM in GDBARCH with internal
>      register id REGNUM.  */
>   void map_raw_register (struct gdbarch *gdbarch, int rawnum, int regnum)
> 
> Right?

No.  There is a many to many mapping.  A cooked register might be
constructed from bits (binary digits) found in both raw hardware
registers and in the target memory.

core-gdb would make a request to either read or write a frame register. 
Those methods, as implemented by the architecture, would be responsible
for the scatter/gather operation required when writing/reading a cooked
register.

core-gdb would also assume the architecture code keeps overlapping
cooked registers coherent.  If register ``foo'' and ``blah'' overlap
then a write to ``foo'' would immediatly be reflected in a read of
``blah''.  This requirement is met by having cooked registers read/write
direct to the register and memory caches.

> To address that complexity, we could formalize the concept of pure
> hardware descriptions, perhaps autogenerated from CGEN.  They would define
> canonical register names, sizes, default types, numeric IDs, default
> groupings, etc.  Targets would provide mappings from their numbers to
> those IDs if necessary.  ISAs could override register names, add
> pseudo-registers, etc.

That is roughly the intent.

Given an ISA family it normally has a well defined register structure. 
The raw register buffer would contain a cannonical set of bits needed to
represent the ISAs register set. The PPC, for instance, has:

	32 64 bit GPRs
	1024 64 bit SPRs
	32 ?? bit AltavecRs

All PPC ISA variants might share a common raw register cache that
contained all of the above.

The architecture code implementing cooked registers could determine
which of the raw registers it needed to access using something like an
enum.

On the target side, either that enum (ppc-linux-nat.c?) or
raw_register_name() (remote.c?) might be used.

> These hardware descriptions could be stored in *-hwdep.c and *-hwdep.h.

Some of the information can live in *-tdep.h.  Other (especially the
structure of a given [Gg] packet) should be hard-wired and then moved to
somewhere completly outside of gdb (include/gdb/remote*blah*.h?) - never
to be touched again.

Eventually, however, there will probably be a shakedown and things like
*-tdep.c will be broken down.

	Andrew