This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Request about adding a new micro support
On Sat, May 23, 2009 at 08:53:52AM +0200, Georg-Johann Lay wrote:
> Ian Lance Taylor schrieb:
> >Alessio Igor Bogani <alessioigorbogani@gmail.com> writes:
> >
> >>Dear Sir Taylor,
> >>
> >>Sorry my mistake. I meant gcc.
> >
> >Ah. gcc supports some 16-bit microprocessors. I'm not aware of any
> >public ports for an 8-bit microprocessor. It's certainly doable, but
> >generally on an 8-bit microprocessor code size is paramount. gcc's
> >optimizations are tuned better for performance than for code size.
> >Also, code code on 8-bit microprocessors can require optimizations which
> >gcc is particularly weak at, such as good use of auto-increment, and
> >coalescing register offsets.
>
> There is an 8-bit Harvard architectures officially supported by gcc,
> namely AVR for C, parts of C++ and Ada.
>
> However, gcc is not well suited for Harvard µC, especially stuff like
> 'near', 'far', 'huge' etc. cannot be supported with a reasonable amount
> of time (It is quite doable in the Backend once you have this expressed
> in terms of machine modes resp. RTL. But the part that is not feasable
> is to introduce new qualifiers and teach gcc to use more than one Pmode).
If the named address space support that Ben Elliston, Ulrich Weigand, and I
have been working on for awhile for the spu port ever clears the final hurdles
to get approved, you will be able to have different sizes of pointers. The
branch that the work is being done on is named-addr-spaces-branch, and I will
be presenting a paper about it at the GCC developers conference next month.
> For AVR, gcc just manages RAM access. Access to other address spaces
> like EEPROM or program memory are handled by user calls to library
> functions or using inline assembler.
>
> As Ian already pointed out, most important for tiny architectures is
> code density.
> However, gcc 4 focuses on speed of bolides and many optimisations in gcc
> 4 have a negative impact on code size. Some of the mess can/could be
> alleviated in the backend, but for AVR the best results still can be
> achieved with latest gcc 3 (both speed and size).
--
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com