This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Ping: [Patch,avr]: Add more devices take #2: 1/2


CCing Richard in case this needs RM approval (I don't think so because the patch just changes ternary parts).

Ping #1 for:
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00577.html
http://gcc.gnu.org/ml/gcc-patches/2013-02/msg00576.html

Georg-Johann Lay schrieb:
Better attach the patch...

Georg-Johann Lay wrote:
Let me drop this, I was thinking too complicated.

src/gas/config/tc-avr.c

reads:

static struct mcu_type_s mcu_types[] =
{
  {"avr1",       AVR_ISA_AVR1,    bfd_mach_avr1},
/* TODO: insruction set for avr2 architecture should be AVR_ISA_AVR2,
 but set to AVR_ISA_AVR25 for some following version
 of GCC (from 4.3) for backward compatibility.  */
  {"avr2",       AVR_ISA_AVR25,   bfd_mach_avr2},
  {"avr25",      AVR_ISA_AVR25,   bfd_mach_avr25},
/* TODO: insruction set for avr3 architecture should be AVR_ISA_AVR3,
 but set to AVR_ISA_AVR3_ALL for some following version
 of GCC (from 4.3) for backward compatibility.  */
  {"avr3",       AVR_ISA_AVR3_ALL, bfd_mach_avr3},
  {"avr31",      AVR_ISA_AVR31,   bfd_mach_avr31},
  {"avr35",      AVR_ISA_AVR35,   bfd_mach_avr35},
  {"avr4",       AVR_ISA_AVR4,    bfd_mach_avr4},
/* TODO: insruction set for avr5 architecture should be AVR_ISA_AVR5,
 but set to AVR_ISA_AVR51 for some following version
 of GCC (from 4.3) for backward compatibility.  */
  {"avr5",       AVR_ISA_AVR51,   bfd_mach_avr5},
  {"avr51",      AVR_ISA_AVR51,   bfd_mach_avr51},
  {"avr6",       AVR_ISA_AVR6,    bfd_mach_avr6},

This means that cores liek avr31, avr35 etc. are supported by binutils and
there is no more the need for avr-gcc to do mappings like avr31 -> avr3.

It appears that avr-gcc implemented these mappings to overcome missing binutils
support for specific cores, and in turn binutils arranged for that kludge...

This means that avr_arch_t need not to be extended to hold the arch mapping for
gas calls and the gas call can use the core name from avr_arch_t.


I broke the patch into two parts:


1/2:  New devices
2/2:  Map device to core to disentangle gcc/binutils interdependencies.

Okay for trunk and 4.7 backport?

Johann


* avr/avr-mcus.def (ata5272, ata5505, attiny1634, ata6285) (ata6286, atmega8a, atmega48pa, ata5790, ata5790n, ata5795) (atmega164pa, atmega165pa, atmega168pa, atmega16hva, atmega16hvb) (atmega16hvbrevb, atmega16m1, atmega16u4, atmega26hvg, atmega32a) (atmega32a, atmega3250pa, atmega3290pa, atmega32c1, atmega32m1) (atmega32u4, atmega32u6, atmega64a, atmega6490a, atmega6490p) (atmega64c1, atmega64m1, atmega64rfa2, atmega64rfr2, atmega32hvb) (atmega32hvbrevb, atmega16hva2, atmega48hvf, at90pwm161) (atmega128a, atmega1284, atmxt112sl, atmxt224, atmxt224e) (atmxt336s, atxmega16a4u, atxmega16c4, atxmega32a4u, atxmega32c4) (atxmega32e5, atxmega64a3u, atxmega64a4u, atxmega64b1, atxmega64b3) (atxmega64c3, atxmega64d4, atxmega128a3u, atxmega128b1) (atxmega128b3, atxmega128c3, atxmega128d4, atmxt540s, atmxt540sreva) (atxmega192a3u, atxmega192c3, atxmega256a3u, atxmega256c3) (atxmega384c3, atxmega384d3, atxmega128a4u): New AVR_MCU. (avrxmega6): Increase max flash segments from 5 to 6. * config/avr/t-multilib: Regenerate. * config/avr/avr-tables.opt: Regenerate. * doc/avr-mmcu.texi: Regenerate.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]