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

[Alain M.]

I have been reading and re-reading this thread, I would like to express 
some thoutghs.

=> Ole and Harald, please pay special attention to option (A) below...

Saving interrupt state is not allways an academic question, it is 
important if-and-only-if you don't know if you are running with 
interrupts enabled or not. As has been said, in ISR it is not nassary to 
call ENTER_CRITICAL_SECTION and there is nothing to restore. and if you 
*know* that IRQ is disabled (true most of the time) you don't need to 
save anything, simple disable()/enable() functions are *much better*.

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!!!

One thing about alloca(): there should be no need of a hidden register 
to control it's use. This is due to the way C manages the stack pointer 
upon return of a function: the original SP is restored and anything 
there is automaticaly freed (ignored).

About the ARM registers: they can allways be used by the compiler 
anytime because even a normal expression can have something implemented 
in a function that can destroy many things. As has been said too, it is 
much better to avoid platform specific functions.

Alain