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

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

Re: [avr-gcc-list] COMPILER Frame pointer bug!!!


From: Bernd Felsche
Subject: Re: [avr-gcc-list] COMPILER Frame pointer bug!!!
Date: Mon, 19 Nov 2001 08:42:34 +0800 (WST)

Christoph Plattner tapped away at the keyboard with:
> Bernd Felsche wrote:
> > Christoph Plattner tapped away at the keyboard with:
> > 
> > > No the code is OK, you simple have overseen the interrupt handling.
> > >
> > > Using cli/sei is ALWAYS WRONG and many old operating system errors
> > > have to be searched. The correct handling is (used C style to
> > > explain):
> > >
> > > flags = save_cpu_flags ();    /* inlcuding Interrupt Enable bit */
> > > cli ();                               /* disable interrupts */
> > >
> > > < critical code >
> > >
> > > restore_cpu_flags (flags);    /* set the old IE state !!! */
> > 
> > Unfortunately, there's the opportunity for an interrupt to occur
> > between the save and the interrupt disable. Or did I miss something
> > in the instruction set details?
> > 
> > This is pretty much a short-coming of the AVR. If the cli() and
> > sei() were both save the previous status of the interrupt flag to
> > (say) the carry bit, then the previous state could be restored
> > reliably, under all circumstances.

> I also thougt about this problem, but if all routines locking
> interrupts or modifying the stats register are written in the
> correct way (with restoring flags) then, there is NO problem, if
> there is an interruption within save-flags and CLI. Because the
> interrupt has to restore the flags, so everything has a consistent
> state. The most CPU architectures I know, cannot save the flags
> and CLI in an atomic way.

An interrupt will firstly clear the bit, then set it if it executes
a RETI to continue previous processing. That's where I was getting
confuddled. Restoring the flags from a saved value is "correct".




reply via email to

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