[En-Nut-Discussion] Fwd: Not fixed!!!: Re: confirmed!!! Re: NutOS 4.4.0 on ARM7: possibly bug in NutEnterCritical / NutExitCritical

[Nathan Moore]

On Fri, Feb 22, 2008 at 4:55 PM, Alain M. <alainm at pobox.com> wrote:

>
>
>
> If-and-only-if a function has to run in both situations, which IIRC will
> only happen in the messaging system, there are a few different options:
>
> A) write different versions, one for the ISR and one for everyone else,
> as well as carefully use buffers to avoid problems. This is the *best*
> solution if there are few points to duplicate, as I believe there are. I
> is faster and probably smaller too.
>
> I have allways implemented queues between foreground and ISR without any
> IRQ disabling, just by carefull coding, just as an example that this can
> be done. (I am not so sure an AVR, but easy on ARM)
>
> B) write a state-saving macro. This is complicated as can be seen in the
> long thread about this topic.
>
> For option (B), I believe that a variable allocated by the compiler
> using "register" type as has been suggested can solve all problems
> because the compiler will optimize it or not, but will allways do it
> right!!!
>
I like this.  I wasn't sure if there was some other reason that it was done
as save/restore.
I thought that it might have been so you could reenter critical sections --
enter, then call a
function that also enters, then exit and exit again without messing
everything up.

Since it is done as macros and inlined anyway the only down side of multiple
interfaces is that
programmers have to know how to use them correctly.  Code will be smaller
and faster than both
local and stack save/restore implementations.

Nathan