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