deferred stores as a solution to store register api?

[Andrew Cagney]

"J.T. Conklin" wrote:
> 
> As has been mentioned on this list before, the (to_store_register) API
> is deficient as it allows exactly one or all registers to be stored at
> a time.  This leads to inefficiencies that add noticeable latency when
> using a remote debug protocol or rom monitor.
> 
> One example is when a small set of registers (commonly pc, sp, and fp)
> are updated sequentially.  If the target vector does not support a
> store single register command, the entire register set is written for
> each update.  Another example is when a large number of registers are
> updated (for example restoring register values after an inferior
> function call).  In this case, it would be more efficient to store all
> registers at once.
> 
> I thinking this can be addressed with minimal impact by formalizing
> the CLEAR_DEFERRED_STORES and DO_DEFERRED_STORES macros currently used
> by the sunos/sparc port by making them part of the target vector.  The
> vector code could then decide whether to store a single, a group, or a
> entire set of registers based on which registers are marked to be
> stored and the capabilities of the target.

How do you expect these extensions to the interface to be used? 
Something like:

	prepare_to_store ();
	store_register ();
	...
	do_defered_stores ();

for a sequence of registers.  What about for a single register?  For
instance:

	(gdb) set $reg = value

would such a write be defered as above or go out immediatly?

	Andrew