On Thu, 30 Mar 2006 14:51:19 -0000, you wrote:
>--- In msp430@msp4..., Jonathan Kirwan
<jkirwan@...> wrote:
>
>> DATA16_N is C's uninitialized variable region. In C, this means
it is
>> actually initialized to semantic 0's before reaching main().
>
>These two statements are a contradiction. If you depend on your C
>compiler zeroing your (non-static) global data, you will have
>portability issues.
>
>The only data that "is actually initialized to semantic 0's before
>reaching main()" are statically declared data, or explicitly
>initialized global data.
>
>Uninitialized, means, uninitialized.
I'll put it abruptly -- you don't define the meaning. It's
simply not
up to you.
There is a semantic meaning for the C language when an initializer is
not specified in the source. But C also includes within that semantic
meaning that such variables, if of static lifetime (meaning that they
exist throughout the program duration), must be initialized to a
semantic zero. All programmers using C have a right to expect this
behavior. It is explicit, not implicit.
This is a semantic meaning that exists within the C language and does
bear upon whether or not a C compiler (which obviously is allowed to
rely upon the C language specifications) may consider uninitialized
data as having a _known_ or an _unknown_ value. In this case, I would
assume that if your statement occurred at a point where the C compiler
could tell itself that the instance was, in fact, 'zero' then the C
compiler could legitimately optimize out the code that also attempts
to set it to zero. The C compiler is permitted this decision.
Whether or not that was the reason, in that case, is another question.
But one that Anders may have to answer. I certainly cannot, but you
might try setting it to something other than zero and see if it still
gets optimized away. My guess and hope is that it won't be.
So far, all this is within the C semantics of "uninitialized." Which
is not necessarily the same thing from a linker point of view. Just
as many other words can carry several distinct semantics to them, so
can the term 'uninitialized.' The linker doesn't need to know
about
the C compiler initialization code's intent to zero out a block. As
far as the linker is concerned, that region/block of data really is
uninitialized. It's the C compiler's problem, including code before
main() to zero it out -- not necessarily the linker's. Of course,
like most other things the real answer here "depends." It is also
possible to define regions to the linker that the linker is required
to consider as "init to hard zero constant" (or any other constant
set, I suppose, whether from a given value or a file or elsewhere.)
But that's a matter for the linker. The primary thing here is what
the C compiler can legitimately _know_. And I think that may be
settled.
You need to change what you imagine as true. That's all. Then it all
makes sense.
Jon
Hi,
> --- In msp430@msp4..., Jonathan Kirwan
<jkirwan@...> wrote:
>
> > DATA16_N is C's uninitialized variable region. In C, this
> means it is
> > actually initialized to semantic 0's before reaching main().
>
> These two statements are a contradiction. If you depend on
> your C compiler zeroing your (non-static) global data, you
> will have portability issues.
>
> The only data that "is actually initialized to semantic 0's
> before reaching main()" are statically declared data, or
> explicitly initialized global data.
In this case, uninitialized means a declaration without initializer
which has come to be called uninitialized data in common parlance.
Initialized data are those that have initializers. Global uninitialized
data is initialized to zero before main. This is all confusing, I know.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by jamie_risk●March 30, 20062006-03-30
--- In msp430@msp4..., Jonathan Kirwan <jkirwan@...> wrote:
> DATA16_N is C's uninitialized variable
region. In C, this means it is
> actually initialized to semantic 0's before reaching main().
These two statements are a contradiction. If you depend on your C
compiler zeroing your (non-static) global data, you will have
portability issues.
The only data that "is actually initialized to semantic 0's before
reaching main()" are statically declared data, or explicitly
initialized global data.
Uninitialized, means, uninitialized.
Reply by Paul Curtis●March 27, 20062006-03-27
Hi,
> I have noticed a few complaints about IAR from
different
> people but I haven't heard anyone mention TI's Code Composer
> Essentials. Before you jump back to command lines and
> makefiles, take a look at CCE. I *think* it runs on linux too...
Eclipse does. CCE doesn't.
--
Paul Curtis, Rowley Associates Ltd http://www.rowley.co.uk
CrossWorks for ARM, MSP430, AVR, MAXQ, and now Cortex-M3 processors
Reply by Rev. Steve Klett●March 27, 20062006-03-27
--- 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.
Reply by Jonathan Kirwan●March 17, 20062006-03-17
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!
Reply by Jonathan Kirwan●March 17, 20062006-03-17
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
Reply by Paul Curtis●March 17, 20062006-03-17
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
Reply by reym...@...●March 17, 20062006-03-17
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.
