Compiler warning on return from inline asm

Go To Last Post
6 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Is there a way to tell gcc that the return statement and everything has been taken care of by the inline assembler?

uint8_t xfer( uint8_t val) {
   asm volatile (
         "1:"
       "\n\t" "subi r24, lo8(1)"
       "\n\t" "breq 1b"
       "\n\t" "ret"\
       :"=r" (val)
       :"0"  (val)
       );
}

The above (minimal) example generates the compiler warning about the missing return statement. If I just add the return statement the compiler also adds its cleanup code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The main problem is that you have a function which returns a uint8_t, but the compiler doesn't see it, so you will get warnings no matter what combo of function attributes you try to fix it (I think). The warning is not about the return, as the compiler will add it (you will see 2 ret's), but about the lack of any return value.

I would try to play nice with the compiler, and write it in a way so that you can return a value, something like-

uint16_t add_1(uint8_t num){
    register uint16_t temp_r24 asm("r24");
    //num=r24=temp_r24
    asm volatile("inc %0" : "=r" (temp_r24) : );
    //return 16bit r25:r24
    return temp_r24;
}

or live with the warning.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem (in my case) with writing a C return statement is that the compiler clears r25 on return.

I guess it can't be done in inline assembler.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Plan C.

//the real function with a void return
//except we WILL 'return' r24
//no need for 'ret', as compiler will add it
//void return gets compiler off our back
void invert_real(uint8_t num){
    asm volatile("com r24");
}

//our 'fake' function with the 'real' return value
//to keep assignment of return value legitimate
uint8_t invert_fake(uint8_t num) __attribute__ ((alias ("invert_real")));

uint8_t temp;
int main(){
    //call our 'fake' function
    //will 'return' ~r24 
    //everybody is happy
    temp = invert_fake(2);
    while(1);
    return 0;
}

it seems to work correctly.

The gcc gurus may now step in and say this is incorrect, or say this has been done to death and where have you been, or something.

The 'alias' attribute appears to completely 'trick' the compiler. No questions asked, or complaints about different return types, etc.

I'm just glad looking at the gcc function attribute web page for the hundredth time is now paying off.

(I actually could use this, I think, and am already thinking of new uses for 'alias')

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Curt, should've thought of that, since I used it lately in a discussion with Dean.

Pretty cool.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What's the advantage of the inline assembler in the first place,
compared to a real assembly file? Much cleaner, better readable,
and does exactly what you tell it to do, no compiler complaints.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.