[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avr-gcc-list] Incorrect code by gcc?

From: hutchinsonandy
Subject: Re: [avr-gcc-list] Incorrect code by gcc?
Date: Thu, 03 Apr 2008 08:42:38 -0400

You are trying to use c as an assembler. Dont do that.

You should be able to ignore frame pointer and register details.

If you have assembler that must have certain values in registers then use asm keyword to create assembler with parameters set to transfer c variable to right registers. Or perhaps write function in assembler as naked function.

But you must follow rules to avoid corruption of gcc. For example, that means you will have to save certain registers such as R28,R29 and R0-R17 - if you use them. Parameters are passed and returned to function in certain registers - so you have to follow that.

See AVR libc/Winavr examples and documentation.


-----Original Message-----
From: Ruud Vlaming <address@hidden>
To: address@hidden
Sent: Thu, 3 Apr 2008 3:10 am
Subject: Re: [avr-gcc-list] Incorrect code by gcc?

On Thursday 03 April 2008 01:15, Andy H wrote:

-fomit-frame-pointer  will work if gcc can really omit it.

Frame pointer will be used to store "local" variables that are to big
to fit in registers and/or need to be saved around calls. It may also
use R2-R17 to save values. Many factors determine which it will use,
such as loops - speed -size - overhead of saving registers etc. It
not always perfect.

If you find situation where it could omit frame pointer - but does
that might be a bug (gcc is not perfect - I know several parts that
could  be better).

In this case (and many others i have seen) there were plenty of registers free to save the variable. I leave it up to you if you call it a bug when i ask the compiler to omit frame pointers and he still uses one. I think he could at least warn if he is unable. In the strict sense it is not a bug since the
documentation states: "Don't keep the frame pointer in a register for
functions that don't need one" Given that gcc is not infinitely smart he
might come to the conclusion he needs one. Gcc could also just use push/
pop to temporarily store the variable, but i don't know if that is always

By all means post "bug" here first if you are not sure.
That was the intention. Next time i wait a little longer to see more
reactions ;-)

I know gcc bugs should have pre-processed sources (.i files) - but as
look it is easier to just look at c code. I think Eric and others
would have
spotted it sooner.
I agree

I would could still use some advise how to resolve the matter. Sometimes
I need to make a function naked to ensure for example all registers are
left in tact when jumping to the context switch, cause normally gcc moves the registers used for parameters first (prolog) to other registers before
making the call.

So how do i force gcc to use a free register or push/pop directly instead
of a frame pointer?

best regards and hope tulips look good.
/  \   /  \   /  \   /  \
|    | |    | |    | |    |
\  /   \  /   \  /   \  /
 ||     ||     ||     ||
 ||     ||     ||     ||
 ||     ||     ||     ||


Ruud Vlaming wrote:
> On Thursday 03 April 2008 00:27, Andy H wrote:
>> Not a bug
> Very good spotting. Andy! Thank you!
> Thats the reason i wanted it to post here before sending in a bug
> Unfortunately i already did so, so i marked the bug as INVALID now.
> The bugnumber was 35807
>> According to the sources you posted,
>> privQueuRequestBody
>> void privQueuRequestBody(uint8_t uiSlot, int8_t siFreeFilling,
uiTicksToWait) __attribute__ ( ( naked ) );
>> The relevant part being "naked"
>> That means gcc will omit prolog - which is where stack and frame
are setup.
>> R28/29 is the frame pointer. What you see in assembler is gcc
saving the
register around a call.
>> Depending on optimization, it may choose to do this rather than
use a
register (as the register would need to be saved on the stack).
>> If you use naked, you must replace all of prolog/epilog by hand.
normal use is for assembler only functions)
> OK, naked is a "dangerous" attribute. I must use it for i do a
context save
just before the
> body function is called, but must preserve all registers so the
parameters are
> left alone.
> Is there a way to prohibit the compiler to do so? In other words
can i
somehow forbid
> to make use of the frame pointer? -fomit-frame-pointer seems not to
do the
> Since i know on beforehand i will not return from
privQueuRequestBody there
is no
> need to save the stack or so.
> Ideas?
> Ruud.
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list

AVR-GCC-list mailing list

AVR-GCC-list mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]