Re: Register group proposal

[Andrew Cagney <ac131313@cygnus.com>]

> It would be interesting then to take the 'grouping' into account by
> the new/next register API. The current semantics of `to_fetch_registers()'
> when a -1 is passed is to fetch all registers. You can see that as
> a group of all registers. I think it's then necessary to clarify or
> extend this semantics.

(Assuming I understand Nick's proposal correctly) The groupings apply to
a frame, they don't apply to the raw register cache - the two should be
kept separate.

Too follow up an earlier posting, the only interface between frame and
frame registers and the raw register cache (ignoring async) would be
something like:

	read_rawreg (cache, rawnum, buf);
	write_rawreg (cache, rawnum, buf);

where RAWNUM shouldn't be confused with a FRAME's REGNUM.

As for tuning register performance.  Think of the raw register cache
just like a CPU cache.  If you get a request to fetch register FOO, then
there is likely benefit in also fetching registers adjacent to FOO.  If
your target is asynchronous (yes OK and GDB is event driven :-), then it
would also be free to quietly continue to fetch FOO related registers
long after the value for FOO has been supplied.

To give examples:

For Chorus, if you were given a request for what you know is a raw
floating point register then you might implement it using a call to
``floating point registers (ie, f0,...)'' and supply all of them.

For a remote target, remote.c might send down a ``G<base>:<bound>'' to
get a block of bytes from the register buffer (a packet extenstion) OR
it might request one register ``P<num>'' (a packet extension) and get
back a bunch of registers (much like the existing ``T'' reply can do
now''.

	Andrew