Re: [avr-gcc-list] Why only registers 18-31?

[Larry Barello]

R18-25 are used for parameter passing between procedures.  R0 &
R1 are temp and zero respectively.  *everything* else is fair
game for GCC temporary storage (pointers, locals, intermediates).
R28, R29 is the frame pointer if needed (gross allocation of
locals, or > four parameter, or > 8 bytes of parameters being
passed )  26,27 and R30,31 are used as pointers.  R2-R17 are used
as locals.  Parameters are often copied into those because the
parameter passing registers are used to, well, pass parameters to
the next routine.  Routines that don't call anything often leave
parameters in their registers and work on them in-place, unless
they are a pointer and then they get moved to X, Y or Z.

Because anywhere on the call chain R18-25 can be used AND they
are not saved by the called procedure, you can't store *anything*
in them.  That is why GCC shuffles stuff into low registers upon
entry into a procedure that calls other procedures.  It is smart,
though, it doesn't shuffle unless it needs to remember something
*after* a call.

So, allocate a bunch (8 bytes) of locals and observe what happens
in the asm.  Then do it for 16 bytes.  Pass 8 bytes of stuff and
observe what happens.  Pass 8 bytes AND allocate 8 bytes of
locals and observe what happens.

You will soon start writing code to optimize code generation on
the AVR!

----- Original Message -----
From: "Jason Kyle" <address@hidden>
...
> >Is there some reason why avr-gcc only uses 18-31 for most of
its work? Is
> >there a way to get avr-gcc to use the rest of the registers?
Would that
> >even be a worthwhile thing to do or would it cause other
problems? My
> >apologies if this is a dumb question; I'm fairly new to
microcontrollers.
>
> Certain opcodes can only use the upper 16 registers, for
example a load
> immediate instruction (LDI Rd,K).  Have a look through the
instruction set
> documentation from Atmel.  A while back someone made a big
table of all the
> instructions which helps in understanding some of those why
Atmel did this
> and that questions.
>
> Cheers,
>
> Jason Kyle
>