Re: [avr-gcc-list] Not naked but "topless" functions?

[Flemming Gram Christensen]

On Fri, Oct 11, 2002 at 09:02:46AM -0700, Larry Barello wrote:
> There is nothing wrong with this prolog.  The CLI clears the interrupt
> enable flag.  When the OUT instruction restores the flag by restoring SREG,
> that doesn't take affect until AFTER the next instructions (read the chip
> data sheets carefully), so the update of the stack will be complete.
> 
> If an interrupt handler modifies and fails to restore *any* register upon
> return, then all code will break regardless of how you write it.   Since
> writing the stack is a two-instruction operation you *must* protect it with
> a CLI/SEI sequence.  GCC just does it in a very clever way with restoring
> the interrupt flag along with the SREG.

I just thought of something.
For small frames (below 5 bytes) wouldn't it be faster
to use a multiple push for stack frame allocation and pops for
stack frame deallocation. 

This way the prologue/epilogue code does not need to interrupt guarded
since the stack and the stackpointer always contains valid values and
the code can then be interrupted at anytime.

Any thing I missed?

Regards
gram

> 
> IMHO the "naked" function is simply broken code.  Unfortunately there is no
> "No Return" attribute implemented for GCC (well, there is, but it has never
> made it into the GCC source) which is what you really want.  I too wrote an
> RTOS (www.barello.net/avrx) and ran into the same sorts of trouble with
> stack usage.  Fortunately, all subroutines called from the top level "naked"
> routine will set up a proper stack frame.  Unfortunately, they will also
> save, on the stack,  all those un-used registers from the top level "naked"
> function.  So, in the end, "naked" doesn't do anything useful.
> 
> I still use the "naked" attribute in my RTOS, but I have the restriction
> that you can't have more than 8 bytes of automatic variables in the top
> level routine (GCC allocates registers, then stack frame variables).
> Fortunately, GCC is so fantastic about register recycling, I can often get
> 10-12 bytes worth of automatics before the compiler needs to resort to the
> frame.  Unfortunately, I have to inspect the resulting assembly all the time
> to make sure modifying the code didn't introduce frame variables which, of
> course, would break.
> 
> Cheers!
> 
> ----- Original Message -----
> From: "Tvrtko A. Ursulin" <address@hidden>
> 
> 
> >
> > Hello everyone!
> >
> > More questions...
> >
> > I need to write functions that dont push/pop registers on stack. But if I
> use
> > __attribute__((naked)) then compiler omits code that adjusts stack pointer
> > also. That is ok if my function uses less than available registers, but if
> > not... trouble.
> >
> > My functions should adjust stack like this:
> >
> >  14e:   cd b7           in      r28, 0x3d       ; 61
> >  150:   de b7           in      r29, 0x3e       ; 62
> >  152:   25 97           sbiw    r28, 0x05       ; 5
> >  154:   0f b6           in      r0, 0x3f        ; 63
> >  156:   f8 94           cli
> >  158:   de bf           out     0x3e, r29       ; 62
> >  15a:   0f be           out     0x3f, r0        ; 63
> >  15c:   cd bf           out     0x3d, r28       ; 61
> >
> > This is taken from function which uses 5 stack variables, hence sbiw
> r28,0x05.
> >
> > Btw, what does in/cli/out of SREG in default function prolog do? If it is
> > supposed to ensure no interrupt occurs while manipulating SP, why "out
> > 0x3f,r0" (enable interrupts right?) is not the last instruction?
> >
> > Thanks!
> >
> > avr-gcc-list at http://avr1.org
> >
> 
> 
> avr-gcc-list at http://avr1.org

-- 
Flemming Gram Christensen, M.Sc., Software Engineer, Mjølner Informatics
------------------------------------------------------------------------
Mjolner Informatics A/S                   Phone:  +45 70 27 43 43       
Helsingforsgade 27                        Fax:    +45 70 27 43 44
DK-8200 Aarhus N, Denmark                 E-mail: address@hidden    
------------------------------------------------------------------------
avr-gcc-list at http://avr1.org