AVR Freaks

Was about to make some snarky comments but this thread is probably best if it is simply allowed to die. Recent posts tread, very close to that issue of "best" (language, compiler, what-ever). Either put on the Nomex or let it sleep!

Jim

C:\SysGCC\avr\bin>type avr.c
#include <avr/io.h>

int main(void) {
        SREG = (1 << SREG_V) | (1 << SREG_T) | (1 << SREG_I);
        if (SREG & (1 << SREG_C)) {
                //soemthing
        }
}

C:\SysGCC\avr\bin>avr-gcc -mmcu=atmega16 -g -Os avr.c -o avr.elf

C:\SysGCC\avr\bin>avr-objdump -S avr.elf | tail -n 20
#include <avr/io.h>

int main(void) {
        SREG = (1 << SREG_V) | (1 << SREG_T) | (1 << SREG_I);
  6c:   88 ec           ldi     r24, 0xC8       ; 200
  6e:   8f bf           out     0x3f, r24       ; 63
        if (SREG & (1 << SREG_C)) {
  70:   8f b7           in      r24, 0x3f       ; 63
                //soemthing
        }
}

C:\SysGCC\avr\bin>type avr.c
#include <avr/io.h>
#include <avr/interrupt.h>

ISR(INT0_vect) {
}

int main(void) {
}


C:\SysGCC\avr\bin>avr-gcc -mmcu=atmega16 -g -Os avr.c -o avr.elf

C:\SysGCC\avr\bin>avr-objdump -S avr.elf | tail -n 30
0000006c <__vector_1>:
#include <avr/io.h>
#include <avr/interrupt.h>

ISR(INT0_vect) {
  6c:   1f 92           push    r1
  6e:   0f 92           push    r0
  70:   0f b6           in      r0, 0x3f        ; 63
  72:   0f 92           push    r0
  74:   11 24           eor     r1, r1
}
  76:   0f 90           pop     r0
  78:   0f be           out     0x3f, r0        ; 63
  7a:   0f 90           pop     r0
  7c:   1f 90           pop     r1
  7e:   18 95           reti

None of which I asked for or that I actually want. This is one of the few cases where I'd use a .S rather than a .c/.cpp if there was a time critical ISR.

<FOR MY PROJECTS>

    C allows me to code the non-critical sections quickly and then iff something needs optimization, do it in assembly (whether in-line or separate .S file).

    I have had projects where there was no choice but pure assembly because EVERY cpu cycle was critical, fortunately (for me) that is very seldom.

</FOR MY PROJECTS>

But that's because you CALL'd a function from an ISR. It does not try to analyze whether the call target is in the current compilation unit or one it may link to later. As such it has to make the worst assumption for the code it cannot see and assume it uses all the registers

@Scrounge: your arguments seems to be re quality of some compiler implementations, and some stupid coders. Not re the C language as such.

And arguing that compiler options should not affect the generated code? That is the point with them!

Tbe one true fact you argue is: With assembler you get full control. That is 100% true.

Since, for most applications, the time-critical code is a small fraction (<10%?), I see it the otger way around. Write bulk in C, analyze time-critical parts, rewrite in assembler.

First optimization is always for maintenance. This rule is no free card for incompetent idiots, though.

Just my $. 05..

#$%$%&&#$@%$ !!! 

If that ability is important or crucial to you, THEN WHY DID YOU CHOOSE THAT TOOLCHAIN?!?

#asm("sei")
...looks like fairly straightforward syntax to me.

interrupt [UART_TXC] void uart_tx_isr(void)
{
#asm
    .equ __tx_buffer_size=8
    push r26
    in   r26,sreg
    push r26
    lds  r26,_tx_counter
    tst  r26
    breq __uart_tx_isr1
    dec  r26
    sts  _tx_counter,r26
    push r27
    push r30
#endasm
...

... and so does this.

But then perhaps I chose the toolchain because...

As long as the pot is being stirred, this is just so "retro"?  "Luddite?  Something.  Back when I was your age, about 30 years ago, and "IBM PC" ruled the world, and C compilers were being rolled out left-and-right -- the one that could indeed take the same Towers of Hanoi source code and get it some cycles shorter would survive.  That was done by having the code generator use standard compiler techniques, and inventing new ones.  Fast-forward 30 years, and what do we get?

I'll still stand behind

I'll opine that with any of the mainstream C toolchains with AVR target, "clean" C, written with the underlying architecture in mind, will turn into very predictable opcode sequences.

I've been told many times here that the beauty of that infinite-value toolchain is that given the open-source nature, anyone an adapt it to their needs and preferences.

yes. So what? As long as the generated code adheres to what the C standard promises, and the compiler produces reasonably efficient code that's no problem. Things that the C standard does not make any promises about: Code efficiency (that is up to the compiler implementor to deliver). Timings - the C standard gives no guarantees for any absolute timings. It only guarantees that the interfacing with the world outside the program will be done as the C code describes. It might take one millisecond or three days to execute. The standard does not care. Again, delivering reasonably performing machine code is up to the implementors.

This is snot specific to C. It holds for more or less any "compiled language".

If there was no difference in results then why would there be options? They are there for just that purpose.

It seems to me that you want the determinism that only coding in assembler can offer. Then stay with assembler.

Meanwhile an awful lot of people actually succeed in writing good functioning programs using C. Speaking only for myself (but I assume it goes for a lot of us) I code much faster in C than in assembler. I have an easier time maintaining code I've written in C, as compared to assembler. I have a decent collection of code that is fully portable between different compilers and target platforms.

You gave a long answer, but still not a hint of what class(es) of microcontroller apps all need to run "flat out".

I just noticed that answer.  But I'll pose the same question:  Give a hint of your class of apps that often/always requires precision timing?