public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Nick Duffek <nsd@redhat.com>
To: eliz@is.elta.co.il
Cc: gdb@sources.redhat.com, kettenis@wins.uva.nl
Subject: Re: Register cache
Date: Mon, 12 Feb 2001 09:46:00 -0000	[thread overview]
Message-ID: <200102121753.f1CHr9t11723@rtl.cygnus.com> (raw)
In-Reply-To: <Pine.SUN.3.91.1010212092158.12969C-100000@is>

On 12-Feb-2001, Eli Zaretskii wrote:

>So you are telling, in effect, that it's okay to have
>i387_supply_fsave get all the FP registers

Yes, I think that's a reasonable and useful i387 interface.

>and x86 targets which don't like that should provide ther own code
>instead of using i387_supply_fsave?

Certainly they can't use i387_supply_fsave, so something like
i387_supply_fpreg would be necessary.

Note that the {supply,fill}_*regset functions aren't part of the register
cache interface: they're just a set of target-specific functions that
several targets happen have in common.

Those targets generally can't fetch just one floating-point register,
which is why the supply_*regset functions lack a REGNO argument.  As Mark
said, the register cache continues to work properly if
target_fetch_registers fetches more registers than requested, so there's
no loss and potentially some gain for those targets to fetch all fp
registers.

If it's possible and more efficient on your target to fetch one fp
register instead of all of them, then I think i387_supply_fpreg is a good
idea.

In my opinion, interface expansion is preferable to code duplication, so I
agree with your patch to put i387_supply_fpreg in i387-nat.c.  However,
that's really a coding philosophy issue, and since Mark wrote i387-nat.c,
I'm inclined to bow to his opinion on how it gets changed.

Nick

  reply	other threads:[~2001-02-12  9:46 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-10 14:37 Mark Kettenis
2001-02-11 12:07 ` Nick Duffek
2001-02-11 23:26   ` Eli Zaretskii
2001-02-12  9:46     ` Nick Duffek [this message]
2001-02-12 10:37       ` Eli Zaretskii
2001-02-16 15:21         ` Mark Kettenis
2001-02-17  0:28           ` Eli Zaretskii
2001-02-17  3:19             ` Mark Kettenis
2001-02-13 13:38 ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2000-08-31  5:50 Register Cache Peter Reilley
2000-08-24 17:01 Wrong PC after external interrupt Fabrice Gautier
2000-08-29 18:01 ` Register Cache Steven Johnson
2000-08-30 21:40   ` Steven Johnson
2001-03-26  6:46   ` Andrew Cagney
2001-03-26  7:22     ` Fernando Nasser
     [not found]       ` <3ABFD062.17EDADAF@neurizon.net>
2001-03-29 16:27         ` Fernando Nasser
2001-03-29 16:27         ` Andrew Cagney

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=200102121753.f1CHr9t11723@rtl.cygnus.com \
    --to=nsd@redhat.com \
    --cc=eliz@is.elta.co.il \
    --cc=gdb@sources.redhat.com \
    --cc=kettenis@wins.uva.nl \
    /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).