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

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

Re: [avr-gcc-list] compiler function prologue/epilogue incorrect?


From: craig
Subject: Re: [avr-gcc-list] compiler function prologue/epilogue incorrect?
Date: Tue, 26 Sep 2006 15:31:26 +0200
User-agent: Mutt/1.4.1i

Hi Paulo

> > [...] What doesn't seem to make
> > sense for me is that SREG is being restored (and perhaps interrupts
> > enabled) before SPL is updated. The assembler tutorial I have
> > suggests that SEI will execute at least one more instruction
> > before reacting to an interrupt but it's not obvious that
> > out 0x3f, r0 will do the same thing or if an interrupt could occur
> > before SPL is updated. 
> 
> The "one more instruction" thing probably has to do with the two level 
> pipeline of this CPU, so it should work for any instruction that updates 
> the interrupt flag, and not just "SEI". At least this has been done like 
> this for a long time and we have never seen any reports of it misbehaving.

OK. The effect of CLI is immediate though so either there is some special
magic for CLI or there might be some other magic associated with SEI and
RETI that produce the extra instruction delay. Hopefully it's CLI that is
special in some way and everyone else gets the 1 instruction delay!

> > I think it would be safer if the compiler
> > swapped the last two lines? The same issue occurs in the function
> > epilogue.
> 
> It is only "safer" if there is any chance of it calling the interrupt 
> right after restoring the flags register.

Yes, that's what I meant. The actual problem would be potentially more
stack usage in the prologue if SPH had been decremented and potential
stack corruption in the epilogue I think if the interrupts could fire
immediately.

> On the down side it would increase the interrupt latency and that can
> be bad for some classes of applications.

One clock cycle is not too bad though :)

I seem to have solved the gcc problem I had by forcing the compiler not
to inline several functions ... gcc-3.3.2 never inlined the code but later
versions did inline. Curiously the function prologue doesn't have this
CLI construct in the non-inlined working version of the code but
I haven't studied the assembly closely enough to be able to say for
sure what was broken in the inlined version yet ...

bye,

--Craig




reply via email to

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