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,
--
Albert.
------------------------------------------------------------------------------
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
