PowerPC 405 support

PowerPC 405 support

[Michael Eager]

I was looking at adding support to GDB for a variant of
the PPC 405.  This variant has several added instructions
but is otherwise the same, i.e., has the same registers, etc.

I thought I'd add a processor type named Xppc405 or ppc405X
for this variant.  Then I noticed that the 405 is really
not supported as a variant, but the 403 is, and that the 403
has extensions (and at least one hack) for the 405.  There
are opcodes defined for PPC405, but this symbol is aliased
to PPC403.

It looks pretty straight-forward to create a ppc405 variant
and unalias it from the ppc403.  Then create a ppc405X
variant which builds on the ppc405.  Any reason not to do
this?

Alternately I could (a) add the variant's instructions
to the existing PPC405 definition and leave that as an
alias for the PPC403.  That would be quick, but seems dirty.

BTW, does anyone have documentation on the PPC403?  I
can't find any online and if I do unalias PPC405 from PPC403,
I'd like to make sure that the opcodes labeled PPC405 are
really only in the 405, and not also in the 403.


-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: PowerPC 405 support

[Daniel Jacobowitz]

On Fri, Jun 23, 2006 at 07:26:22PM -0700, Michael Eager wrote:
> I was looking at adding support to GDB for a variant of
> the PPC 405.  This variant has several added instructions
> but is otherwise the same, i.e., has the same registers, etc.
> 
> I thought I'd add a processor type named Xppc405 or ppc405X
> for this variant.  Then I noticed that the 405 is really
> not supported as a variant, but the 403 is, and that the 403
> has extensions (and at least one hack) for the 405.  There
> are opcodes defined for PPC405, but this symbol is aliased
> to PPC403.
> 
> It looks pretty straight-forward to create a ppc405 variant
> and unalias it from the ppc403.  Then create a ppc405X
> variant which builds on the ppc405.  Any reason not to do
> this?

I'm going to guess here, but probably this would be a better suited
question for binutils@.  GDB doesn't really have much knowledge about
PPC variants, just the bits it inherits from libopcodes.

-- 
Daniel Jacobowitz
CodeSourcery

Re: PowerPC 405 support

[Michael Eager]

Daniel Jacobowitz wrote:
> On Fri, Jun 23, 2006 at 07:26:22PM -0700, Michael Eager wrote:
> 
>>I was looking at adding support to GDB for a variant of
>>the PPC 405.  This variant has several added instructions
>>but is otherwise the same, i.e., has the same registers, etc.
>>
>>I thought I'd add a processor type named Xppc405 or ppc405X
>>for this variant.  Then I noticed that the 405 is really
>>not supported as a variant, but the 403 is, and that the 403
>>has extensions (and at least one hack) for the 405.  There
>>are opcodes defined for PPC405, but this symbol is aliased
>>to PPC403.
>>
>>It looks pretty straight-forward to create a ppc405 variant
>>and unalias it from the ppc403.  Then create a ppc405X
>>variant which builds on the ppc405.  Any reason not to do
>>this?
> 
> 
> I'm going to guess here, but probably this would be a better suited
> question for binutils@.  GDB doesn't really have much knowledge about
> PPC variants, just the bits it inherits from libopcodes.

Maybe so.  Most are handled by the opcode tables and bfd.
I'll ask on the binutils list.

There is some PPC variant code in rs6000-tdep.c, defining
recognized variant names, defining registers and referencing
the correct bfd entry.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

Re: PowerPC 405 support

[Daniel Jacobowitz]

On Fri, Jun 23, 2006 at 08:22:41PM -0700, Michael Eager wrote:
> Maybe so.  Most are handled by the opcode tables and bfd.
> I'll ask on the binutils list.
> 
> There is some PPC variant code in rs6000-tdep.c, defining
> recognized variant names, defining registers and referencing
> the correct bfd entry.

Right.  Unless you make manual effort for it, though, that code is
never activated - mostly you'd need to be talking to a JTAG device to
see the different registers anyway.  It'll use whatever architecture
BFD tells it to, or pass a name from "set architecture" back to BFD.

-- 
Daniel Jacobowitz
CodeSourcery