public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
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

             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).