This is the mail archive of the
mailing list for the GCC project.
Re: More useful support for low-end ARM architecture
- From: Joey Ye <joey dot ye dot cc at gmail dot com>
- To: Joern Rennecke <joern dot rennecke at embecosm dot com>
- Cc: Markus Hitter <mah at jump-ing dot de>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 13 Nov 2014 09:37:37 +0800
- Subject: Re: More useful support for low-end ARM architecture
- Authentication-results: sourceware.org; auth=none
- References: <545E7221 dot 4090005 at jump-ing dot de> <CAL0py27DZ3r-z+5AXN8o+gZhHt2CJMEtWtKP26DXYdup3QYutA at mail dot gmail dot com> <CAMqJFCq5D_HOL3rBRUZGZuD7TzkTY6tA9whoTBmv4CFP9D28qw at mail dot gmail dot com>
On Wed, Nov 12, 2014 at 1:47 AM, Joern Rennecke
> On 11 November 2014 16:22, Joey Ye <email@example.com> wrote:
>> * Expensive effort. Either supporting none, or supporting all. There
>> are large number of MCUs from ARM eco-system partners. Supporting all
>> of them is a large project.
>> * Maintance nightmare. Having GCC developers to input and maintain
>> vendor specific configurations is inefficient and error-prone.
>> * Failed schedule dependence. Having -mmcu actually means whenever
>> there is a new MCU introduced into market, GCC has to be updated to
>> describe it. Given GCC's release cycle (once per year) and the
>> frequency of MCU release (could be tens each year), GCC will never be
>> able to catch up.
> These kinds of issues were why I re-implemented the avr -mmcu option
> with the SELF_SPEC mechanism to read a device-specific spec file.
> As long as a new mcu can be described with the existing toolchain facilities
> (e.g. a new combination of existing I/O support, some different parameters
> describing RAM / flash sizes), a new spec file can be distributed together
> with a few hardware-specific library/crt files to support a new mcu with
> an existing compiler.
Indeed. Took a look at the patch and I have to say it is a quite smart idea.
>> Further more all the board/MCU specific configurations are already
>> described in CMSIS and variant of GUI based toolchain for ARM MCU.
>> Replicating then in GCC does not sounds a right thing to do for me.
> Yes, better to have a script that translates this info into a suitable spec file
> and copies any required files in the appropriate installation places.
> Not sure what kind of Copyright/licensing issues that would entail, though
I would think of a separate project, where people can add new NCU
configuration there independent to GCC.