Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Corinna Vinschen <vinschen@redhat.com>
To: gdb-patches@sources.redhat.com
Subject: Re: [RFA] sh-tdep.c: optimize and rename virtual register conversion functions
Date: Mon, 16 Feb 2004 15:55:00 -0000	[thread overview]
Message-ID: <20040216155533.GI18953@cygbert.vinschen.de> (raw)
In-Reply-To: <16432.57568.176468.343897@localhost.redhat.com>

On Feb 16 10:25, Elena Zannoni wrote:
> Corinna Vinschen writes:
>  > Hi,
>  > 
>  > the functions sh_sh4_register_convert_to_virtual and
>  > sh_sh4_register_convert_to_raw are only called once each.  In both
>  > cases, the register numbers are already tested for the correct range,
>  > before the function is actually called.  Therefore it's possible to
>  > optimize the register number tests away from both functions.
>  > 
>  > Also, I'd like to propose to rename both functions to get rid of the
>  > "sh4" in the name.  The functions are universal so I'd like to reuse
>  > them for an upcoming SH variant with different virtual register numbering,
>  > if that's ok.
> 
> 
> Can you elaborate a bit about this new SH variant?

It will introduce a couple of new real registers which requires to
increment the pseudo double precision register numbers.  At the moment
I can't go into too much detail otherwise.

> Is the test in the
> function conflicting with a different test for the new variant? 

Actually, it was a thinko on my side.  The new variant will result
in incrementing SH_NUM_REGS but when I sent this patch, I was still
using another register count for this very cpu.  Therefore, the
register test is only superfluous, nothing else.  It does not conflict
with anything.

So, if you think that the test should be kept in that function, that's
fine with me.  The only remaining bit is the naming of the function then. 
The new cpu is not a sh4 type, but it's using the same pseudo register
functions as the sh4.  The function would just not be sh4 specific anymore.


Corinna

-- 
Corinna Vinschen
Cygwin Developer
Red Hat, Inc.


  reply	other threads:[~2004-02-16 15:55 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-02-10 16:14 Corinna Vinschen
2004-02-10 16:17 ` Corinna Vinschen
2004-02-16 15:29 ` Elena Zannoni
2004-02-16 15:55   ` Corinna Vinschen [this message]
2004-02-16 16:20     ` Elena Zannoni
2004-02-16 16:52       ` Corinna Vinschen

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=20040216155533.GI18953@cygbert.vinschen.de \
    --to=vinschen@redhat.com \
    --cc=gdb-patches@sources.redhat.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