On 10/01/12 19:48, JMGross wrote:
>
> I agree that common subexpression elimination can be done across code blocks,
> but then this wouldn't be anything that will affect a critical section, as a
> common
> subexpression IMHO cannot be critical, else it weren't common.
> I'd be surprised to see any other, critical optimization jumping out of a
> while loop.
> But yes, I noticed that even a really nasty optimization
> (not to clean up the stack after an sprintf call) ends at a code block border.
> (nasty on MSPs with ony 256 bytes of ram)
> I agree that there is nothing that keeps a compiler from optimizing across
> a code block. Since optimization is not regulated or covered by the C language
> standard at all. Nor are interrupts (that make critical sections necessary).
> So at the end it comes down to the compiler implementation.
> And the insight that there is no way to _ensure_ portability of critical
> sections
> across compilers or even different versions of the same compiler.
>
> Well, this insight (and some related) is one of the reasons why I still work
> with the 3.23 version of mspgcc. All of our code was written for it and works
> with this version. And on a compiler change, everything must be tested again.
>
> JMGross
There is no fixed definition of "critical optimisation" or "important
code". All sorts of code can be moved across code blocks. Even if you
have seen no problems with optimisations you have tested so far, on code
you have written, and with the current versions of the compiler, there
is no guarantee that will apply in the future.
I have seen code that did some calculations that involved library calls
(for division), then disabled interrupts, set a register with the result
of the calculation, then re-enabled interrupts. The library calls ended
up inside the critical section. It's a valid optimisation by the
compiler - it knows nothing about timing of volatile accesses, only
their ordering.
So your choices are to limit yourself to old tools with limited
optimisations, to write code that forces the ordering (such as by using
artificial volatile accesses), or to manually qualify the exact assembly
output of such critical routines and avoid changing compiler versions in
the middle of a project.
Personally, I use the later two methods combined.
mvh.,
David
>
> ----- Ursprüngliche Nachricht -----
> Von: David Brown
> An: mspgcc-users@lists.sourceforge.net
> Gesendet am: 09 Jan 2012 14:17:33
> Betreff: Re: Simulation and algorithm timing
>
> On 09/01/2012 12:43, JMGross wrote:
>>
>> A 'trick' that has helped in the past to put code into a 'cage' is
>> doing just that: put it into a cage.
>>
>> do {...}while(0);
>>
>> The compiler shouldn't optimize across the code block barrier. I'm
>> not sure what the C standard says about this, but in the past, this
>> perfectly worked. I use this as default for critical section in my
>> atomic macro:
>>
>> #define ATOMIC(x) do{ intcount++; __disable_interrupts();
>> do{x}while(0); if (!(--intcount))__enable_interrupts();}while(0)
>> (reconstructed from memory)
>>
>> The only disadvantage I encuntered so far is that the round macro
>> parameter brackets are not identified as code block delimites by the
>> editor.
>>
>
> The compiler /should/ optimise across the code blocks - it is not a
> barrier of any sort. You may accidentally have achieved your purpose
> because some optimisations are limited to a single code block - but
> there is absolutely no reason to expect it to work.
>
> You have to remember that the compiler generates code /as if/ it
> translated your code directly - which means it follows volatile
> accesses, but can re-arrange the rest of the code as it sees fit.
>
> mvh.,
>
> David
>
>
>> JMGross
>>
>> ----- Ursprüngliche Nachricht ----- Von: David Brown An: Peter Bigot
>> Gesendet am: 08 Jan 2012 02:08:50 Betreff: Re: [Mspgcc-users]
>> Simulation and algorithm timing
>>
>> Not only /may/ actions (calculations, non-volatile read/write
>> accesses, etc.) be moved across volatile accesses, but it has been
>> seen to happen in practice, causing some confusion to posters on
>> lists like this and the equivalent avr-gcc mailing lists.
>>
>> In particular, people seem to get quite upset when the compiler
>> moves code back and forth across interrupt disable/restore pairs!
>>
>>
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
