Re: additional vector function to improve register fetch performance

[jtc at redback dot com (J.T. Conklin)]

>>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>> Might be changed to:
>> 
>> prefetch_sp ();
>> prefetch_fp ();
>> prefetch_pc ();
>> prefetch_register (R0_REGNUM);
>> sp = read_sp ();
>> fp = read_fp ();
>> pc = read_pc ();
>> r0 = read_register (R0_REGNUM);
>> 
>> (I'm assuming the prefetch* functions are added to regcache.c to do
>> whatever housekeeping is required and call the target vector
>> function).

Andrew> To follow on from Stephane's comments.  I have a feeling that
Andrew> this would make things unnecessarily complicated.
Andrew>
Andrew> Looking at the remote case and the ``T'' packet.  There isn't
Andrew> any reason why the ``T'' packet doesn't just return all of the
Andrew> registers.  Across a TCP connection that should have zero
Andrew> marginal cost.

Note that while I primarily use the remote protocol, I am looking at
this issue of register fetch performance more generically.

The problem is that the upper layer of GDB do not communicate with the
target layer in such that a target that can perform different types of
register fetches can select the optimum one.  

This is not an issue if the target can only fetch the entire register
set.  But I think it is desirable if a target can fetch a subset of
registers so that GDB would take advantage of that ability.

Imagine a processor with 32 4-byte integer registers, 32 4-byte float-
ing point registers, and a handful of control and other miscellaneous
registers.  If registers are ascii-hex encoded, the register data will
be ~1K bytes.  On a 9600bps link, assuming no other overhead, it will
takes over one second to receive.  If there was some way to fetch only
the registers that were needed, we'd be able to significantly improve
that time.  Even if the protocol is only able to fetch a single register,
assuming "reasonable" command latency GDB might be able to issue multiple
fetch register commands in less time.

The reason I suggested a cache model is that caches and prefetching
are already well understood concepts.  

Andrew> The other thing to consider is given a request for reg N, the
Andrew> target could satisfy it by fetching an entire block of
Andrew> registers M<=N<=O and entering them all into the cache.

How are M and O selected?  A target specific back end has knowledge
about the target and can select an appropriate block: Wind River's WDB
breaks things into integer registers, floating point registers,
control registers, etc. which works quite well in practice.  But I
don't know how something similar could be done with a generic target 
like remote.c

Andrew> In away the ``G'' (registers) packet does this - you ask for
Andrew> one register and get back a block.  Unfortunatly the block is
Andrew> very very large and fixed.

Agreed.  And as long as the remote protocol only requests full packets,
performance is reasonable.  But if you added support for a fetch single
register command to complement the existing store single register 
command, I think you would find that performance would suffer because 
GDB would fetch multiple single registers when a single register fetch 
would be optimal.  Today can see the same with single register stores in
some circumstances.  

I think we could recommend that single register stores only be
implemented for those targets where DECR_PC_AFTER_BREAK != 0.

        --jtc

-- 
J.T. Conklin
RedBack Networks