avr-gcc-list
[Top][All Lists]
Advanced

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

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


From: Ruud Vlaming
Subject: Re: [avr-gcc-list] Incorrect code by gcc?
Date: Thu, 3 Apr 2008 16:24:10 +0200
User-agent: KMail/1.9.1

Thank you for you assistance Andy,
I entered a bug report in my own project ;-)

Somehow i will find a solution. Knowing it
is an frame pointer matter , looking around
on internet learned me that more people
have had similar problems. One person even
suggested we need the new attribute "bikini" :-)


On Thursday 03 April 2008 14:42, you wrote:
> You are trying to use c as an assembler. Dont 
> do that. You should be able to ignore frame
> pointer and register details.

Well maybe, if i can ignore all that i rather 
use Eiffel of Java or so. I need C because it
is a machine language and i am programming
the smallest avr, no bytes spoiled. I want to 
have control over the code, but i don't want 
to write bare assembler because it is so hard 
to maintain. It is a matter of taste i guess.

Regards
Ruud.


> -----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 
> is
> > not always perfect.
> >
> > If you find situation where it could omit frame pointer - but does 
> not,
> > 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
> possible.
> 
> > 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 
> first
> > 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.
> 
> 
> > 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 
> report.
> > > 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, 
> uint16_t
> uiTicksToWait) __attribute__ ( ( naked ) );
> > >>
> > >> The relevant part being "naked"
> > >>
> > >> That means gcc will omit prolog - which is where stack and frame 
> pointer
> 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. 
> (its
> 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 
> function
> 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
> trick.
> > >
> > > 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
> > address@hidden
> > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> >
> 
> 
> _______________________________________________
> AVR-GCC-list mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
> 
> 




reply via email to

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