Re: [avr-gcc-list] Urgent Queries about AVR-GCC

[Neil Johnson]

Hi,

Joerg Wunsch wrote:
> "Suresh B Joshi" <address@hidden> wrote:
>
> > (1) Any function whose return value is only 8 bits
> >     (i.e. unsigned char), the GCC-AVR compiler still
> >     clears the R25 register using eor R25,R25 instruction.
>
> This is a documented feature.
>
> See
> http://savannah.nongnu.org/download/avr-libc/doc/avr-libc-user-manual/FAQ.html#faq_reg_usage
> (last paragraph).

To quote:

"Return values: ... 8-bit return values are zero/sign-extended to 16 bits
by the caller ..."

So, in that case why do we see an instruction to clear R25 in the callee,
when the manual says this should be done by the caller?  It would make
sense for the caller to do the zero-extension, so that if analysis
determines this is not necessary then the offending instruction can be
omitted.

> > (2) When using the switch statement, even if the control
> >     expression is an unsigned char variable, it is promoted
> >     to 16 bit unsigned int, by eor R25,R25 instruction.
>
> IMHO, this is required by the C standard.  Also, you quote enums as an
> example, they are (unfortunately) always equivalent to type "int".

See my last post.  Agreed about enums though, but that's a different issue
to the switch controlling expressions and case values.  I think what is
happening here is that the constants for the cases are treated as
integers, and so the compiler is promoting the type of the controlling
expression to match that of the case values, which is type "int".

What would be nice to do is for the compiler to do range analysis on the
set of case values, and determine that they fit into the range of char,
and thus avoid promoting the controlling expression from a char to an int.

The best compiler I've seen for compact embedded code is the Keil C51
compiler.  Very smart compiler indeed.  Does amazing things with switches.

> > (3) When calling functions within same source files, the
> >     use of "call" instruction need not be employed for
> >     AVR processors with memory higher than 8K bytes.
>
> The code generator would need to ensure that no single source file
> could generate more than 8 KB of code then.  A single source file does
> not automatically guarantee any specific code size limit.

This is more of an issue for the linker to sort out, although we could be
heading into NP-completeness if we try and pack the functions in such a
way as to minimize the size of call instructions.  It might be good enough
just to do it opportunistically, so it would be up to the programmer to
place his/her functions in local clumps.

Again, the Keil C51 compiler/linker does this, together with lots of other
cool stuff (global register allocation being another example).

Still, at the end of the day GCC is free, generates code which works, and
is free.  I don't think _anyone_ has the right to complain if the code is
not as good as commercial compilers.  As they say, "you gets what you pay
for".

Cheers,
Neil

--
Neil Johnson :: Computer Laboratory :: University of Cambridge ::
http://www.njohnson.co.uk          http://www.cl.cam.ac.uk/~nej22
----  IEE Cambridge Branch: http://www.iee-cambridge.org.uk  ----