From: jtc@redback.com (J.T. Conklin)
To: gdb@sourceware.cygnus.com
Subject: additional vector function to improve register fetch performance
Date: Thu, 07 Dec 2000 14:17:00 -0000 [thread overview]
Message-ID: <5m3dfzj2qs.fsf@jtc.redback.com> (raw)
While we're talking about register fetch and stores, I had an idea the
outher night about improving performance by adding some new functions
to the target vector.
* target_prefetch_register()
With the register cache and targets that always fetch the entire
register set, fetch performance is as good as can be expected. But
with a target that can fetch one register at a time, GDB will issue
multiple single register fetches. Due to command/response latency,
this has a significant performance impact.
One way this could be addressed is to always fetch the entire
register set. The remote protocol is like this, while it can set a
single register, there is no command to fetch one. This approach
may lose when the register set is large and the number of registers
to be fetched is small; it may be possible to issue several single-
register fetches in the time for one for the entire register set.
Another is the proposed target_prefetch_register() vector function.
All this does is do a hint that we'll need the value of a register
sometime "soon". A sequence like:
sp = read_sp ();
fp = read_fp ();
pc = read_pc ();
r0 = read_register (R0_REGNUM);
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).
In a trival target, prefetch would do nothing. In one that has a
async protocol, it might start fetching those registers (a callback
would install the value in the cache when the values were received).
In one that could do single, or full register set fetches, it might
defer fetching anything until the first "real" read was received.
At that time it would decide whether what type of fetch is the most
optimum to perform.
The disadvantage of this is that there is no benefit if the prefetch
hints aren't added. The good thing is that it keeps the interface
between the target independent and target specific parts of GDB
reasonably clean. For contrast, imagine of a target vector function
that took a list of registers to read. This (IMO) would be much
more difficult to use effectively.
Thoughts? I have some partially thought ideas on how to do the same
for register stores, but I'm going to wait until they've firmed up a
bit before sharing.
--jtc
--
J.T. Conklin
RedBack Networks
next reply other threads:[~2000-12-07 14:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-12-07 14:17 J.T. Conklin [this message]
2000-12-14 16:59 ` Andrew Cagney
2000-12-15 14:56 ` J.T. Conklin
2000-12-08 2:53 Stephane Carrez
2000-12-11 15:21 ` J.T. Conklin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5m3dfzj2qs.fsf@jtc.redback.com \
--to=jtc@redback.com \
--cc=gdb@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).