Ian Lance Taylor schrieb:
Alessio Igor Bogani <alessioigorbogani@xxxxxxxxx> 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).
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).
Perhaps you should also consider one of pcc, sdcc or tcc.
Georg-Johann
