On 17/10/17 14:45, Andrew Haley wrote:
> On 17/10/17 13:32, David Brown wrote:
>> No, you can't - not always. Memory clobbers enforce an ordering on data
>> that is stored in memory or loaded from memory. They don't affect data
>> in registers, and they don't affect code execution and calculations.
>
> Yes, of course. So you need to insert *artificial* dependencies, as needed,
> to make the ordering explicit.
>
>> And memory clobbers are expensive on many targets, as are alternatives
>> like making extra volatile variables.
>
> But you show in the rest of your mail that you do understand the issue, and
> some solutions. The "do not perform this expensive operation while interrupts
> are disabled" problem is indeed tricky because GCC doesn't model time at this
> level. But there are ways to be explicit, and you evidently know what they are.
>
Yes, I do know how to be explicit about these dependency issues. But I
am always interested in different ways to handle them - either to make
them easier, or to get better generated code. And while I know a lot
here, I certainly don't know everything on the topic.
And while /I/ know about them, most users don't - this is advanced
stuff. Most programmers want to be able to able to write:
#include <interrupt_control.h>
unsigned int ivar;
void test2( unsigned int val )
{
val = 65535U / val;
cli();
ivar = val;
sei();
}
and have interrupts disabled for a minimal number of clock cycles.
They want to write:
void test1(void) {
foo_start();
ENTER_CRITICAL();
foo_critical();
EXIT_CRITICAL();
foo_end();
}
and know that all of "foo_critical()", and only "foo_critical()", is
executed within the critical section (with perhaps some register caching
of data across the boundaries). They want this to happen whether these
functions are defined in the same source file or different ones, and for
any optimisation level. It is reasonable to expect people to understand
about volatile data - but not about inline assembly and dependencies.
Perhaps you could say they should know about memory barriers (using a
macro from the library header), but not that they should understand
about when a memory barrier is not enough.
You can expect the author of ENTER_CRITICAL and EXIT_CRITICAL to
understand everything involved - that is the job of a library author.
So how do you implement these macros in a way that is efficient,
correct, and safe to use? Including memory barriers in the form of
memory clobbers certainly helps, though it can mean less optimal code -
give the "normal" users sub-optimal but ease and safe macros, and let
the advanced (or obsessive!) users fix the dependencies themselves. But
as we have seen, memory barriers are not necessarily enough. There is
no "execution barrier".
