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 <[EMAIL PROTECTED]> > To: avr-gcc-list@nongnu.org > 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 > > > AVR-GCC-list@nongnu.org > > > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list > > > > > > > > > _______________________________________________ > > AVR-GCC-list mailing list > > AVR-GCC-list@nongnu.org > > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list > > > > > _______________________________________________ > AVR-GCC-list mailing list > AVR-GCC-list@nongnu.org > http://lists.nongnu.org/mailman/listinfo/avr-gcc-list > > _______________________________________________ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
