On 07/01/12 18:01, Albert ARIBAUD wrote:
> Le 07/01/2012 17:28, Grant Edwards a écrit :
>> On 2012-01-07, Peter Bigot<big...@acm.org> wrote:
>>> On Sat, Jan 7, 2012 at 9:00 AM, Grant Edwards<grant.b.edwa...@gmail.com>
>>> wrote:
>>>
>>>> It's quite possible that the 4.x compiler is more aggressive about
>>>> moving stuff around. ?When working on low level stuff like an MSP430,
>>>> I pretty much always have my Makefiles set up to generate mixed
>>>> C/assmebly language listings so that it's easy to keep an eye on what
>>>> the compiler is doing. ?One advantage of that is that you quickly
>>>> learn what C constructs are handled efficiently by the compiler wand
>>>> what aren't -- you learn that the smallest, fastest way to do things
>>>> in C on an MSP430 is not the same as on an AVR.
>>>
>>> The 4.x compilers (especially 4.6.x) do optimize much more
>>> aggressively, but if you use the defined peripheral registers like
>>> P2OUT mspgcc had better not re-order them across sequence points,
>>> since those are marked volatile. If you do see something like this,
>>> it's almost certainly a bug and I'd appreciate it being reported on
>>> the SF tracker.
>>
>> However the "test code" might be non-volatile, and as such GCC is
>> still free to move it outside the set/clear pair (AFAICT). The GCC
>> documentaion I've found appears to indicate that the restriction on
>> moving code across sequence points only affects volatile accesses.
>> Quoting from
>> http://gcc.gnu.org/onlinedocs/gcc-4.5.3/gcc/Volatiles.html#Volatiles
>>
>> The minimum either standard specifies is that at a sequence point
>> all previous accesses to volatile objects have stabilized and no
>> subsequent accesses have occurred.
>>
>> Note that the GCC docs only say that _volatile_ accesses can't be
>> moved across sequence points. More searches reveal similar statements
>> along with a few seemingly well-informed postings where it is
>> explicitly stated that non-volatile accesses may be moved across
>> sequence points.
>>
>> For example from http://blog.regehr.org/archives/28 (which appears to
>> be a rather well-informed article):
>>
>> Summary: Most compilers can and will move accesses to non-volatile
>> objects around accesses to volatile objects, so don't rely on the
>> program ordering being respected.
>>
>> I don't know if it's still an issue, but at one point he mentions a
>> "volatile" bug in MSP430:
>>
>> Compilers are not totally reliable in their translation of accesses
>> to volatile-qualified objects. I've written extensively about
>> this subject elsewhere, but here's a quick example:
>>
>> volatile int x;
>>
>> void foo (void) {
>> x = x;
>> }
>>
>> The proper behavior of this code on the actual machine is unambiguous:
>> there should be a load from x, then a store to it. However, the port
>> of GCC to the MSP430 processor behaves differently:
>>
>> $ msp430-gcc -O vol.c -S -o -
>> foo:
>> ret
>>
>> [I don't know which version of mspgcc that refers to, and it's not
>> really related to our topic but it does lead me to believe that the
>> author knows what he's talking about.]
>>
>> Anyhow.... I can't find anywhere in GCC docs that say non-volatile
>> accesses can't be moved across sequence points or volatile accesses.
>> If sequence points and volatile accesses only constrain ordering of
>> accesses to volatile objects, and what you're timing doesn't involve
>> volatile objects, then adding sequence points doesn't matter.
>>
>> However, adding a memory barrier ought to do the trick. I think.
>>
>> Pointers to GCC docs actually stating what to expect would be
>> most welcome...
>
> I believe sequence points are not *global* sync points, but rather,
> points between specific sections of code where the section "before"
> *has* to execute first and the section after has to execute second. For
> instance (see annex C of ISO IEC 9899:201x) the evaluation of a
> function's arguments and address must be completely done before the
> actual call, so there is a sequence point between the former and latter,
> but the whole thing *might* not have sequencing constraints wrt to some
> other code which may then be interleaved with it. So for instance, in
>
> a = func_1(b,c);
> d = func_2(e,f);
>
> each assignment has a sequence point right before the call, so
> evaluation of b and c (resp. e and f) will sequence before call to func1
> (resp. func2) and assignment to a (resp. d), but there is no ordering of
> the two assignments wrt each other, so their code might well be
> interleaved and we cannot predict which of a or d will be assigned
> first, despite there being two sequence points in that code.
>
> IOW, sequence points do not define total ordering of execution, they
> denote partial ordering.
>
> Amicalement,
The key thing to remember is that the compiler doesn't have to treat
sequence points as any sort of synchronisation points - it only has to
generate code that acts /as if/ they were synchronisation points, with
respect to the visible actions of the program. The visible actions of
the program are its inputs and outputs, and any volatile reads or writes.
So the compiler obeys sequence points regarding volatile accesses - any
failure here is a serious bug. But it is perfectly free to move any
non-volatile accesses, calculations, and even function calls (if it
knows they don't have volatile accesses) across volatile accesses.
Memory barriers, such as asm volatile("" ::: "memory"), are a great help
in limiting movement, but be aware that even this does not prevent the
movement of calculations or actions that don't access memory (such as
actions involving only local variables).
------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual
desktops for less than the cost of PCs and save 60% on VDI infrastructure
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
