Re: [avr-gcc-list] Global variables and ISRs ???

[David Brown]

> > generated with basic -O optomisation is far easier to read and
understand than code
> > generated with -O0, since it keeps variables in registers instead of the
> > stack.
>
> Oh, that's interesting... because as soon as I compile my small
> programs, I rush to check to have a look at the assembler output, to get
> the hang of things, and am often very confused by the way the compile
> does things, it's often very obscure !

gcc is good at re-arranging things to generate better code, and can
sometimes make confusing output.  I find -O output far easier to read
than -O0, but if you really want to generate easy-to-read code I would guess
it is best to start with -O, then use compiler flags to turn off certain
optomisation passes, such as those that re-arrange the order of the code.
That would involve a lot of trial-and-error and manual reading to get a nice
choice of flags - a rainy-day project.


> So far I have noticed a few recurrent things...
>
> - at start-up, to initialize variables to zero... it won't write zero
> into them (immediate constant I mean), instead it will always copy R1
> into the variable. Apparently R1 is kept cleared at all times and is
> used whenever a variable needs to be cleared.
>

Yes, it is referred to as "__zero_reg" in the generated assembly.  I think
there is some disagreement as to how useful it is in practice, and whether
it is worth reserving a register for zero operations, but it's useful for
things like comparisons with zero, or for clearing a variable (the AVR has
no instructions to store an immediate value directly to memory).

> - everytime I want to increment a variable, instead of just using the
> "INC" or "DEC" instructions, it prefers to substract the complement...
> just as fast (one cycle), but boy not exactly as "readable"/clear as
> "INC" or "DEC", insn't it ?! :-/
>

The output is optomised for compiler-generation rather than human
readability.  The "sbci" instruction is used because there is no "adci" in
the AVR instruction set (there was no need, since "sbci" does the job).

>
> - everytime I test if a variable is zero or not, it AND's it with
> itself... instead of just using the dedicated 'TST' instruction.
>

The "TST" instruction actually is an "emulated" instruction - if you look at
the description in Atmel's documentation, "TSR rx" is implemented as "AND
rx, rx".  Similarly, "CLR rx" is just "EOR rx, rx".  Some ports of gcc
generate emulated instructions, some generate the explicit equivilent.

>
> So it doesn't make it very easy for me to learn the AVR's assembler...
>

Examining compiler output is seldom a good way to learn a cpu's assembler,
although it is a good way for learning about the code the compiler produces
for a given source construct.

>
> The optimazation option is "-Os" as that's what is used in avr-libc's
> documentation, which I used to get me started with using the tool-chain.
> Maybe gcc-avr should have a new option : "if you have the choice between
> two ways of doing thing, that will take the same space and clock
> cycle... please take the one that's most readable by human
> beings" !! ;o)
>
>
> > > is a problem in your code also - you are not making
> > > flag=0 after you send back the character. HTH.
> > That's certainly true - I suppose he'd have noticed if his program had
got
> > far enough...
>
> No boys, not a bug, a feature !! ;-P
> That said, once this worked, I did clear the flag so I can enjoy seeing
> it working more than just once, without having to reset the AVR, but it
> didn't really add anything, since I already knew it was working even
> when the flag wasn't cleared...
>
>
> --
> Vince
>
>
>
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
>