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

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

Re: [avr-gcc-list] GCC guru question (progue/epilogue sequences)


From: Kang Tin LAI
Subject: Re: [avr-gcc-list] GCC guru question (progue/epilogue sequences)
Date: Fri, 26 Jul 2002 23:24:00 +0800

Possible be accepted? But I have no idea how to submit the changes and
put into the mainstream source.....we expecting such function are not
the most people of the avr-gcc community.....

Kang Tin LAI

Larry Barello wrote:
> 
> Now might be a good time to push to get your mod's put into the
> source...
> 
> ----- Original Message -----
> From: "Lai Kang Tin" <address@hidden>
> To: <address@hidden>
> Sent: Thursday, July 11, 2002 11:07 PM
> Subject: Re: [avr-gcc-list] GCC guru question (progue/epilogue
> sequences)
> 
> > So everytime I upgrade the GCC, I have to change and recompile the
> GCC
> > adding a "nonret" Non-return attribute, which is identical to
> "naked"
> > but setuping the frame properly for local vars.
> >
> > Kang Tin LAI
> >
> > On Tue, 9 Jul 2002, Larry Barello wrote:
> >
> > > In my RTOS (www.barello.net/avrx) I do the same thing you do.
> Since
> > > GCC allocates up to 8  bytes of locals out of registers, kernel
> > > functions have the restriction that there be no more than 8 bytes
> of
> > > locals and you don't do anything that requires a frame (e.g. take
> the
> > > address of a local).
> > >
> > > The NAKED attribute is unfortunate in that it doesn't set up the
> > > frame.  What is really needed is a "No Return" attribute so that
> > > registers are not saved by GCC and the RTOS can handle context
> > > switches without chewing up so much SRAM.
> > >
> > > In assembler, where I control everything, AvrX runs comfortably in
> a
> > > 2313. With GCC AvrX needs an 8515 to do useful work since each
> context
> > > needs, at a minimum, 35 bytes before any that GCC uses.
> > >
> > > Note: as soon as you call a function (from your task or interrupt
> > > handler) you get a valid frame and GCC pushes a bunch of registers
> > > that are likely unused at the top (naked) level.
> > >
> > > Cheers!
> > >
> > > ----- Original Message -----
> > > From: "Marko Panger" <address@hidden>
> > > To: <address@hidden>
> > > Cc: "AVR Mailing List" <address@hidden>
> > > Sent: Tuesday, July 09, 2002 2:23 PM
> > > Subject: Re: [avr-gcc-list] GCC guru question (progue/epilogue
> > > sequences)
> > >
> > >
> > > HI again !
> > >
> > > My INT handler looks like
> > >
> > > RTOS_INTERRUPT(VECTOR_NUMBER)        /*naked attribute*/
> > > {
> > >     uint16_t var1;        /* this is a variable used by the user*/
> > >
> > >     IntEnter();        /*here I save registers*/
> > >
> > >     User code bla...bla;
> > >     bla;
> > >     bla;
> > >
> > >     IntExit();        /* here I    swap context*/
> > > }
> > >
> > > As you can se I am doing a sort of pro/epi by my own. I should
> save
> > > the entire context in IntEnter() because the user code could make
> an
> > > another task ready to run, so the context is swapped in IntExit().
> Now
> > > the extra code generated by the compiler is redundant and more -
> it
> > > wastes ram (PUSH, POP).
> > >
> > > After IntEnter() Y and the SP are the same. My prologue sequence
> > > should be:
> > >
> > > in r28, SPL
> > > in r29, SPH
> > > sbiw r28, NUMBER OF BYTES REQUIRED BY USER LOCAL VARIABLES
> > > out    SPL, R28
> > > out    SPH, R29
> > >
> >
> > --------------------------------------------------------------------
> --
> > > ---------------
> > > Anyway I have just solved the problem with a little trick:
> > >
> > > RTOS_INTERRUPT(VECTOR_NUMBER)        /*naked attribute*/
> > > {
> > >     IntEnter();        /*here I save registers*/
> > >
> > >     UserFunction();
> > >
> > >     IntExit();        /* here I    swap context*/
> > > }
> > >
> > > void UserFunction(void);
> > >
> > > Thanks for helping me !
> > >
> > > Regards,
> > > Marko P.
> > >
> > >
> > >
> > > ----- Original Message -----
> > >   From: Marc R. Wetzel
> > >   To: Marko Panger ; AVR Mailing List
> > >   Sent: Tuesday, July 09, 2002 11:05 PM
> > >   Subject: RE: [avr-gcc-list] GCC guru question (progue/epilogue
> > > sequences)
> > >
> > >
> > >   Did you had a look at ethernut? Something very useful is already
> > > there. This project
> > >   looks always for contributors.
> > >
> > >   To your question:
> > >
> > >   if an interrupt occurs your kernel has no chance to save any
> > > registers. so the pro/epilogue is very helpful.
> > >   your kernel will be interrupted and it is not clear -- when.
> > >
> > >   Look at the ethernut-way: it uses a kind of wrapper for any
> possible
> > > interrupt source available.
> > >   and if you attach an real interrupt-handler to it, it will be
> > > called.
> > >
> > >   Hopefully I understand your question right...
> > >
> > >   /Marc
> > >     -----Original Message-----
> > >     From: address@hidden
> > > [mailto:address@hidden Behalf Of Marko Panger
> > >     Sent: Tuesday, July 09, 2002 10:56 PM
> > >     To: AVR Mailing List
> > >     Subject: [avr-gcc-list] GCC guru question (progue/epilogue
> > > sequences)
> > >
> > >
> > >     Hi all !!
> > >
> > >     I realy hope somebody could answer the following question. I
> will
> > > try to explain the situation and my problem.
> > >
> > >     So... I am writting a RTOS and I would like to have interrupt
> > > handlers written in C language. If I define a function as a
> INTERRUPT
> > > or SIGNAL the compiler generates the prologue/epilogue sequence
> > > automaticaly. But I don't need this. Registers saving an restoring
> is
> > > managed by my kernel.
> > >
> > >     There is another possibility. I could decalre the interrupt
> > > function with NAKED attribute. This would be fine for me since the
> > > compiler doesn't generate the prologue/epilogue sequence. But here
> > > comes the problem. What will happen if I decalare some local
> variables
> > > wich are putted on the stack ?
> > >
> > >     I was wondering if is possible to write my own pro/epi
> sequences ?
> > > How will I now how many variables are putted onto the stack ?
> > >
> > >
> > >
> > >
> > >
> > > avr-gcc-list at http://avr1.org
> > >
> >
> > K.T.LAI
> > address@hidden
> >
> >
> > avr-gcc-list at http://avr1.org
> >
avr-gcc-list at http://avr1.org



reply via email to

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