Re: [avr-gcc-list] "Mixed" Assembly Listings (and Degenerate I/O Code Examples)

[Joerg Wunsch]

"Bruce D. Lightner" <address@hidden> wrote:

> The ability to see the AVR machine code "in context" with the source
> code is an *essential* feature of any compiler "tool kit" used for
> embedded programming.

However, the more advanced the compilers and the CPUs get, the more
you'll notice that there's no longer a 1:1 relation between the C code
and the generated assembly.  For genuine RISC machines, this has been
true now for about 15 years now or so.  According to the rules of the
C language, the compiler is free to reorder stuff as it sees fit, as
long as the result is the same.  But that kind of rearrangment makes
it close to impossible to show you the C context in the assembly
program, as subexpressions of a single C source line can get scattered
around.

The only world where you can really see a 1:1 match is i386, and
that's mainly due to the stupidity of that machine: it suffers from a
constant lack of free registers, so there's not much potential for
that kind of optimizations.  (Instead, the CPU makers started to
perform the compiler's job inside the CPUs itself there, so the
reordering happens on the lowest level.)

The AVR is about in the middle between both worlds.  It already shows
a good deal of RISC behaviour, and this can be observed in the
compiled code as well.  It doesn't experience other RISC peculiarities
though like the possibility to execute a register and a memory
operation in parallel (and thus increase the overall speed), so
there's no point in the excessive rearrangements I've seen on genuine
RISCs.  Still, I've seen compiled AVR code that could simply no longer
be matched against the original C code in large parts, yet it was a
beautiful translation of the developer's intention.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)