[rfc] Use target descriptions for PowerPC

[Thiago Jung Bauermann]

Hi Daniel,

A few more comments, in the hope they can be useful.

On Fri, 2007-10-05 at 12:37 -0400, Daniel Jacobowitz wrote:
> -/* PowerPC UISA - a PPC processor as viewed by user-level code.  A UISA-only
> -   view of the PowerPC.  */
> -static const struct reg registers_powerpc[] =
> -{
> -  COMMON_UISA_REGS,
> -  PPC_UISA_SPRS,
> -  PPC_ALTIVEC_REGS
> -};
> -
> -/* IBM PowerPC 403.
> -
> -   Some notes about the "tcr" special-purpose register:
> -   - On the 403 and 403GC, SPR 986 is named "tcr", and it controls the
> -     403's programmable interval timer, fixed interval timer, and
> -     watchdog timer.
> -   - On the 602, SPR 984 is named "tcr", and it controls the 602's
> -     watchdog timer, and nothing else.
> -
> -   Some of the fields are similar between the two, but they're not
> -   compatible with each other.  Since the two variants have different
> -   registers, with different numbers, but the same name, we can't
> -   splice the register name to get the SPR number.  */
> -static const struct reg registers_403[] =
> -{
> -  COMMON_UISA_REGS,
> -  PPC_UISA_SPRS,
> -  PPC_SEGMENT_REGS,
> -  PPC_OEA_SPRS,
> -  /* 119 */ S(icdbdr), S(esr),  S(dear), S(evpr),
> -  /* 123 */ S(cdbcr),  S(tsr),  SN4(tcr, ppc_spr_403_tcr), S(pit),
> -  /* 127 */ S(tbhi),   S(tblo), S(srr2), S(srr3),
> -  /* 131 */ S(dbsr),   S(dbcr), S(iac1), S(iac2),
> -  /* 135 */ S(dac1),   S(dac2), S(dccr), S(iccr),
> -  /* 139 */ S(pbl1),   S(pbu1), S(pbl2), S(pbu2)
> -};
> -
> -/* Motorola PowerPC 860 or 850.  */
> -static const struct reg registers_860[] =
> -{
> -  COMMON_UISA_REGS,
> -  PPC_UISA_SPRS,
> -  PPC_SEGMENT_REGS,
> -  PPC_OEA_SPRS,
> -  /* 119 */ S(eie), S(eid), S(nri), S(cmpa),
> -  /* 123 */ S(cmpb), S(cmpc), S(cmpd), S(icr),
> -  /* 127 */ S(der), S(counta), S(countb), S(cmpe),
> -  /* 131 */ S(cmpf), S(cmpg), S(cmph), S(lctrl1),
> -  /* 135 */ S(lctrl2), S(ictrl), S(bar), S(ic_cst),
> -  /* 139 */ S(ic_adr), S(ic_dat), S(dc_cst), S(dc_adr),
> -  /* 143 */ S(dc_dat), S(dpdr), S(dpir), S(immr),
> -  /* 147 */ S(mi_ctr), S(mi_ap), S(mi_epn), S(mi_twc),
> -  /* 151 */ S(mi_rpn), S(md_ctr), S(m_casid), S(md_ap),
> -  /* 155 */ S(md_epn), S(m_twb), S(md_twc), S(md_rpn),
> -  /* 159 */ S(m_tw), S(mi_dbcam), S(mi_dbram0), S(mi_dbram1),
> -  /* 163 */ S(md_dbcam), S(md_dbram0), S(md_dbram1)
> -};
> -
> -/* Motorola PowerPC 601.  Note that the 601 has different register numbers
> -   for reading and writing RTCU and RTCL.  However, how one reads and writes a
> -   register is the stub's problem.  */
> -static const struct reg registers_601[] =
> -{
> -  COMMON_UISA_REGS,
> -  PPC_UISA_SPRS,
> -  PPC_SEGMENT_REGS,
> -  PPC_OEA_SPRS,
> -  /* 119 */ S(hid0), S(hid1), S(iabr), S(dabr),
> -  /* 123 */ S(pir), S(mq), S(rtcu), S(rtcl)
> -};
> -
> -/* Motorola PowerPC 602.
> -   See the notes under the 403 about 'tcr'.  */
> -static const struct reg registers_602[] =
> -{
> -  COMMON_UISA_REGS,
> -  PPC_UISA_SPRS,
> -  PPC_SEGMENT_REGS,
> -  PPC_OEA_SPRS,
> -  /* 119 */ S(hid0), S(hid1), S(iabr), R0,
> -  /* 123 */ R0, SN4(tcr, ppc_spr_602_tcr), S(ibr), S(esasrr),
> -  /* 127 */ S(sebr), S(ser), S(sp), S(lt)
> -};
> -
> -/* Motorola/IBM PowerPC 603 or 603e.  */
> -static const struct reg registers_603[] =
> -{
> -  COMMON_UISA_REGS,
> -  PPC_UISA_SPRS,
> -  PPC_SEGMENT_REGS,
> -  PPC_OEA_SPRS,
> -  /* 119 */ S(hid0), S(hid1), S(iabr), R0,
> -  /* 123 */ R0, S(dmiss), S(dcmp), S(hash1),
> -  /* 127 */ S(hash2), S(imiss), S(icmp), S(rpa)
> -};
> -
> -/* Motorola PowerPC 604 or 604e.  */
> -static const struct reg registers_604[] =
> -{
> -  COMMON_UISA_REGS,
> -  PPC_UISA_SPRS,
> -  PPC_SEGMENT_REGS,
> -  PPC_OEA_SPRS,
> -  /* 119 */ S(hid0), S(hid1), S(iabr), S(dabr),
> -  /* 123 */ S(pir), S(mmcr0), S(pmc1), S(pmc2),
> -  /* 127 */ S(sia), S(sda)
> -};
> -
> -/* Motorola/IBM PowerPC 750 or 740.  */
> -static const struct reg registers_750[] =
> -{
> -  COMMON_UISA_REGS,
> -  PPC_UISA_SPRS,
> -  PPC_SEGMENT_REGS,
> -  PPC_OEA_SPRS,
> -  /* 119 */ S(hid0), S(hid1), S(iabr), S(dabr),
> -  /* 123 */ R0, S(ummcr0), S(upmc1), S(upmc2),
> -  /* 127 */ S(usia), S(ummcr1), S(upmc3), S(upmc4),
> -  /* 131 */ S(mmcr0), S(pmc1), S(pmc2), S(sia),
> -  /* 135 */ S(mmcr1), S(pmc3), S(pmc4), S(l2cr),
> -  /* 139 */ S(ictc), S(thrm1), S(thrm2), S(thrm3)
> -};

I see that the comments above about variants have been removed. Some of
them mention different processor models which also fit the register
description, and others describe choices made and restrictions with the
register descriptions. Is it worthwhile to transport these to the XML
files?

>    {"601", "Motorola PowerPC 601", bfd_arch_powerpc,
> -   bfd_mach_ppc_601, -1, -1, tot_num_registers (registers_601),
> -   registers_601},
> +   bfd_mach_ppc_601, &tdesc_powerpc_601},
> +  /* FIXME */
>    {"602", "Motorola PowerPC 602", bfd_arch_powerpc,
> -   bfd_mach_ppc_602, -1, -1, tot_num_registers (registers_602),
> -   registers_602},
> +   bfd_mach_ppc_602, &tdesc_powerpc_602},

I'd suggest adding a description about what the FIXME above refers to.

> @@ -3780,17 +3404,6 @@ rs6000_gdbarch_init (struct gdbarch_info
>    switch (info.osabi)
>      {
>      case GDB_OSABI_LINUX:
> -      /* FIXME: pgilliam/2005-10-21: Assume all PowerPC 64-bit linux systems
> -         have altivec registers.  If not, ptrace will fail the first time it's
> -         called to access one and will not be called again.  This wart will
> -         be removed when Daniel Jacobowitz's proposal for autodetecting target
> -         registers is implemented. */
> -      if ((v->arch == bfd_arch_powerpc) && ((v->mach)== bfd_mach_ppc64))
> -        {
> -          tdep->ppc_vr0_regnum = 71;
> -          tdep->ppc_vrsave_regnum = 104;
> -        }

The FIXME is being removed above. Was this issue fixed already? It seems
it's not, so maybe the FIXME could be moved to somewhere else, like
ppc-linux-nat.c where I believe the behaviour comes from?

BTW, both powerpc-32.xml and powerpc-64.xml include the altivec feature,
so you are assuming that ppc32 has altivec registers as well, right?
-- 
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center