Dear all,

I've been argueing with IAR's support for some time about this.
Since we could not a conclusion yet, I'd like to hear your optinion.

The statement is

*(int*)__segment_begin("DATA16_N") = 0;

There s a certain constallation where the compiler entirely throws this
instruction away.  (No, it's not dead code.)

In my opinion this is illegal according to the language as the compiler
cannot judge whether this is superfluous or not.

Literally the statement for the compiler is:
"There's a symbol which you don't know, but the linker does!  So
please
write zero to the adress of that symbol!"


regards
Dirk

Hi, 

> I've been argueing with IAR's support
for some time about this.
> Since we could not a conclusion yet, I'd like to hear your optinion.
> 
> The statement is
> 
> *(int*)__segment_begin("DATA16_N") = 0;
> 
> There s a certain constallation where the compiler entirely 
> throws this
> instruction away.  (No, it's not dead code.)
> 
> In my opinion this is illegal according to the language as 
> the compiler
> cannot judge whether this is superfluous or not.
> 
> Literally the statement for the compiler is:
> "There's a symbol which you don't know, but the linker does!
 
> So please
> write zero to the adress of that symbol!"

Ok, a bit weird, but this should not be optimized out at all:

*(volatile int *)(__segment_begin("DATA16_N")) = 0;

--
Paul Curtis, Rowley Associates Ltd  http://www.rowley.co.uk
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

Thanks Paul!

Of course, you're right.

I've forgotten to note that I already have a fix for my programm.
'volatile' helps under all circumstances, or partially turning
optimization
off.
Even appending 'asm("");' after the critical command makes
it reappear.

The question just was, whether the compiler's behaviour is legal or not.

regards
Dirk

On Fri, 17 Mar 2006 15:28:28 -0000, Paul wrote:

>> I've been argueing with IAR's
support for some time about this.
>> Since we could not a conclusion yet, I'd like to hear your
optinion.
>> 
>> The statement is
>> 
>> *(int*)__segment_begin("DATA16_N") = 0;
>> 
>> There s a certain constallation where the compiler entirely 
>> throws this
>> instruction away.  (No, it's not dead code.)
>> 
>> In my opinion this is illegal according to the language as 
>> the compiler
>> cannot judge whether this is superfluous or not.
>> 
>> Literally the statement for the compiler is:
>> "There's a symbol which you don't know, but the linker
does!  
>> So please
>> write zero to the adress of that symbol!"
>
>Ok, a bit weird, but this should not be optimized out at all:
>
>*(volatile int *)(__segment_begin("DATA16_N")) = 0;

Exactly what I was thinking when I read the other post.

Jon

Dirk, 

> Of course, you're right.
> 
> I've forgotten to note that I already have a fix for my programm.
> 'volatile' helps under all circumstances, or partially 
> turning optimization off.
> Even appending 'asm("");' after the critical command
makes it 
> reappear.
> 
> The question just was, whether the compiler's behaviour is 
> legal or not.

As there is no contextual information (i.e. no way to know what comes
before or after that statement) there is no definitive answer that can
be made.  If the compiler knows that the location is zero either before
or after the assignment, your assignment statement may be safely removed
by the compiler.

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

Dear Paul (and all others),

once more I have to fully agree.
I omitted the full code because the context is actually somewhat strange
and brings more confusion than help, I'm afraid.

The facts are:
The reference to the segment "DATA16_N" is not used in any other place
of the module.  So the compiler cannot know the actual location and
therefore
cannot analyze any interaction with the rest of the code.

This brings me to the crux of the matter:
IMHO "The compiler may optimize something out if it can clearly see,
that the instruction is redundant.  If there should be any doubt, the code
must be left as is."
I think this mostly correlates with your second statement below.


What made me wonder was another statement I heard quite often
in this discussion (not on this mailing list):
"The compiler does not clearly see, that I'm doing something with that
memory location afterwards, so can simply throw the instruction away."


So basically the question is what to do with an instruction, when the
compiler
does not see all interaction outside the current module, i.e. when there is
a doubt.
Leave it or dump it?


regards
Dirk


Paul wrote:
>As there is no contextual information (i.e. no way to know what comes
>before or after that statement) there is no definitive answer that can
>be made.  If the compiler knows that the location is zero either before
>or after the assignment, your assignment statement may be safely removed
>by the compiler.

Hi, 

> This brings me to the crux of the matter:
> IMHO "The compiler may optimize something out if it can 
> clearly see, that the instruction is redundant.  If there 
> should be any doubt, the code must be left as is."
> I think this mostly correlates with your second statement below.
> 
> What made me wonder was another statement I heard quite often 
> in this discussion (not on this mailing list):
> "The compiler does not clearly see, that I'm doing something 
> with that memory location afterwards, so can simply throw the 
> instruction away."
> 
> So basically the question is what to do with an instruction, 
> when the compiler does not see all interaction outside the 
> current module, i.e. when there is a doubt.
> Leave it or dump it?

The compiler can only remove the instruction if it can prove that it is
redundant.  Simple as that.  What reasons were given by your vendor to
indicate that it *is* redundant and therefore be removed?

--
Paul Curtis, Rowley Associates Ltd   http://www.rowley.co.uk 
CrossWorks for MSP430, ARM, AVR and now MAXQ processors

On Fri, 17 Mar 2006 17:51:51 +0100, Dirk wrote:

>Dear Paul (and all others),
>
>once more I have to fully agree.
>I omitted the full code because the context is actually somewhat strange
>and brings more confusion than help, I'm afraid.
>
>The facts are:
>The reference to the segment "DATA16_N" is not used in any other
place
>of the module.  So the compiler cannot know the actual location and
>therefore
>cannot analyze any interaction with the rest of the code.
><snip>

But this still depends on the context, perhaps.  Paul's comment (and
you seem to agree) is that if the C toolset can determine if that
location is already 0, then it can remove the code (when there is no
'volatile' present to qualify the pointer.)

DATA16_N is C's uninitialized variable region.  In C, this means it is
actually initialized to semantic 0's before reaching main().  Your
reference is [not having read the docs on __segment_begin("DATA16_N")
but assuming this means the first address assigned via the .xcl file]
may, depending on context, take place at a time when the compiler
_can_ make that determination.

Without a detailed explanation from IAR and your context it is hard
for a 3rd party to make a considered determination.

Jon

On Fri, 17 Mar 2006 17:04:52 -0000, Paul wrote:

>> This brings me to the crux of the matter:
>> IMHO "The compiler may optimize something out if it can 
>> clearly see, that the instruction is redundant.  If there 
>> should be any doubt, the code must be left as is."
>> I think this mostly correlates with your second statement below.
>> 
>> What made me wonder was another statement I heard quite often 
>> in this discussion (not on this mailing list):
>> "The compiler does not clearly see, that I'm doing something 
>> with that memory location afterwards, so can simply throw the 
>> instruction away."
>> 
>> So basically the question is what to do with an instruction, 
>> when the compiler does not see all interaction outside the 
>> current module, i.e. when there is a doubt.
>> Leave it or dump it?
>
>The compiler can only remove the instruction if it can prove that it is
>redundant.  Simple as that.  What reasons were given by your vendor to
>indicate that it *is* redundant and therefore be removed?

Now you got me started....  ;)

Let's have an option allowing a detailed exposition of the reasons for
all optimizations applied to DAGs, broader basic blocks, or sections
of code bounded by #pragmas, etc. in a special text file output of the
compiler (which may be appended to by the linker of course.)  It
should assume that the unoptimized assembly output is available for
review and then show the work each and every step of the way on
indicated sections, as desired.

I'd love it!!

Jon


P.S.
Since I'm rolling, ....

(*) One that allows the C compiler to test out and apply appropriate
various valid topological transformations, as suggested earlier by the
'gcd' discussion.

(*) Include an optimizing assembler (free, of course) which can, for
example, transform the 32-unsigned divided by 16-unsigned MSP430 code
supplied by TI's application note example into a much faster version,
automatically.  In fact, it keep at it until some specified metric of
"better" is achieved, too.  It should use a simulated annealing
process over the entire program, using various sized (to start,
randomly sized but quickly moving towards optimally sized) rectangles
of overlapping code sections in a parallel process of gradual code
improvement against the specified metrics.  (The rate of the
"temperature" decline should be settable, so that it will actually
sometimes move more often towards poorer code early on, before later
moving more uniformly towards better code, in order to find locally
optimal code arrangements.)

...So, in an ongoing effort to sincerely help provide tool vendors
with more time for envelope-pushing efforts such as the above, there
is...

Kirwan's observer principle for programming tools:

   Tool vendors may not spend a single second that doesn't go towards
   improving the quality of the toolset, as observed exclusively by a
   hypothetical user who _only_ uses a command line interface for
   their development.  Features which cannot be seen by this
   hypothetical user but which can be seen by a Windows user are
   determined to be pointless sizzle instead of good meat and are
   therefore a waste of good time on bad features.

No more adding of font color choices, docking windows, print previews,
GUI page setup dialogs, GUI make files, etc.  Features enhancing other
window features in some bizarre, telescoping, endless regression of
craziness.

I want to edit and compile code.  But when I ask to edit something, I
don't want to be asked:  Would you like that editor window to be
vertical or horizontal?  Red or green borders?  Pink keywords, just
plain, or would you like to select from this gorgeous list I have
here?  Would that be sans serif Arial or serif'd Times Roman, today?
For the entire file or just comment lines?  Would that be all the
editor windows you'd like to close or just the inactive ones?  Should
I remember which were which for next time?  Would you like to vary
this for Tuesdays or may I dare to presume this all week for you?

Cripes!

--- In msp430@msp4..., reymannd@... wrote:
>
> Dear all,
> 
> I've been argueing with IAR's support for some time about this.
> Since we could not a conclusion yet, I'd like to hear your optinion.
> 
> The statement is
> 
> *(int*)__segment_begin("DATA16_N") = 0;
> 
> There s a certain constallation where the compiler entirely throws this
> instruction away.  (No, it's not dead code.)
> 
> In my opinion this is illegal according to the language as the compiler
> cannot judge whether this is superfluous or not.
> 
> Literally the statement for the compiler is:
> "There's a symbol which you don't know, but the linker does!
 So please
> write zero to the adress of that symbol!"
> 
> 
> regards
> Dirk
>


Hi,

Where I work we use the MSP430 quite a bit and use IAR exclusively.
Our experience is to just turn all optimization off. IAR is nutorious
for optimizing out code that is actually used. My opinion of the IAR
tools is not very high for other reasons also. The people at IAR are
quite proud of their work and will defend it fiercly even when they
know they have a problem.

I must admit that having an editor that will format and place the
cursor for braces is great for productivity. Its also very nice to
have different parts of the code in colors. It lets the eye and the
mind quickly identify the various aspects of the code.

I am an old DOS head and worked many years from the command line. I
did not cross over to Wiondows until Win98. I must admit that a GUI
that will do most of the grunt work for you is nice. It allows you to
concentrate on the task at hand, coding, instead of being tied up
creating the build files. I would not want to regress but
unfortunately that is what we will probobly do. It appears that we
will be crossing over to Linux.