Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: Elena Zannoni <ezannoni@redhat.com>, gdb-patches@sources.redhat.com
Subject: Re: [RFA] rs6000-tdep.c: initial support for e500
Date: Tue, 20 Aug 2002 13:57:00 -0000	[thread overview]
Message-ID: <1020820205743.ZM26087@localhost.localdomain> (raw)
In-Reply-To: Elena Zannoni <ezannoni@redhat.com> "[RFA] rs6000-tdep.c: initial support for e500" (Aug 20,  4:16pm)

On Aug 20,  4:16pm, Elena Zannoni wrote:

> This patch adds the initial machinery for supporting the Motorola e500
> processor.
> 
> I added registers and pseudo registers in this patch.
> I will follow up with abi changes soon.
> 
> The e500 processor has vector registers which are 64 bit long.  The
> lower 32 bits of such registers are the same as the general registers
> (hence the pseudos).  No floating point registers in this processor.
> 
> Elena
> 
> 2002-08-19  Elena Zannoni  <ezannoni@redhat.com>
> 
> 	* ppc-tdep.h (struct gdbarch_tdep): Add ev registers.
> 
> 	* rs6000-tdep.c (rs6000_register_virtual_type): Return 64 bit
> 	vector type for ev registers.
> 	(e500_pseudo_register_read): New function.
> 	(e500_pseudo_register_write): New function.
> 	(e500_dwarf2_reg_to_regnum): New function.
> 	(PPC_UISA_NOFP_SPRS): New macro.
> 	(PPC_EV_REGS): New macro.
> 	(PPC_GPRS_PSEUDO_REGS): New macro.
> 	(registers_e500): New register set for e500.
> 	(variants): Add e500 variant.
> 	(rs6000_gdbarch_init): Move setting of pc, sp, fp regnums to
> 	before setting architectural dependent variations.  Initialize ev
> 	registers numbers.  Add case for e500 architecture.  Set the
> 	number of pseudo registers.

Okay.

The fact that the register numbers are so wildly different from any
existing PPC port bothers me a bit, but I'll get over it.  (Actually,
the fact that they can vary as they did is a pretty good indicator
that we've gotten things right elsewhere.  I wonder though if there
might not be a few places which still assume that gpr0 is 0 and gpr31
is 31.  Hmm... yes, rs6000-nat.c has some code like this.)

If I understand things correctly, the pseudo register numbers aren't
set in stone, right?  E.g, if there should come a day when we discover
that some other register ought to be added, we could add it between the
existing "real" registers and the pseudos, right?

Before checking your patch in, take a look at the comments you added and
make sure you have two spaces after each period.  Also make sure that
comments which contain sentences have periods at the ends.

Kevin


  reply	other threads:[~2002-08-20 20:57 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-08-20 13:18 Elena Zannoni
2002-08-20 13:57 ` Kevin Buettner [this message]
2002-08-20 15:27   ` Elena Zannoni

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=1020820205743.ZM26087@localhost.localdomain \
    --to=kevinb@redhat.com \
    --cc=ezannoni@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