From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Stephane Carrez Cc: nsd@redhat.com, gdb@sources.redhat.com, fnasser@redhat.com, insight@sources.redhat.com Subject: Re: Register group proposal Date: Wed, 21 Feb 2001 09:34:00 -0000 Message-id: <3A93FBBC.8AAA4558@cygnus.com> References: <200102211100.MAA29081@sunchorus.France.Sun.COM> X-SW-Source: 2001-02/msg00277.html > 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:'' to get a block of bytes from the register buffer (a packet extenstion) OR it might request one register ``P'' (a packet extension) and get back a bunch of registers (much like the existing ``T'' reply can do now''. Andrew