When I saw your initial comment John, I thought "Wow, that's gonna insult
all compiler writers"
(Mainly because your 'achieving benchmarks' comment is complete crap).
I'd rather be an innocent
bystander, but your reaction is too far left field I thought.
In fact, I'm surprised no other tool vendors have attempted to get all your
8 cylinders firing
again.
> The isssue of not using volatile with a delay loop is
very well known
> for those who are experienced.
Richard, the OP, enunciated that he WAS using volatile qualifiers, so the last
squirm of "missing
context" is rather futile IMO.
I'm all for standing up for the 'underdog' and/or the righteous.
But first of all they have to be
correct and/or properly informed - you're not.
The bottom line is that YOU raped context. You took Richard's post as an
excuse/disguise to lash
out at C tool vendors.
I have my own gripes - like many - but if you have one, come straight out with
it and don't
perform some bumbling charade many can look through (and don't get huffy
when they do).
In other words (in case you still don't get it), respond to Richard to help
him, not to make a
fool of yourself. It helps no one, including yourself.
-- Kris
-----Original Message-----
From: m... [mailto:m...] On Behalf Of John Heenan
Sent: Monday, 26 May 2008 10:22 PM
To: m...
Subject: [msp430] Volatile and delay loops
With the context reinserted, instead of removed to make spiteful
personal attack on me from some of the most boring, unimaginative,
spiteful and unemployable people on the planet, your compiler with
optimisation turned on is liable to turn, contrary to your
instructions
{
unsigned char x=0xFF;
while(xx--);
}
into absolutely nothing unless you use instead
{
volatile unsigned char x=0xFF;
while(xx--);
}
The isssue of not using volatile with a delay loop is very well known
for those who are experienced.
John Heenan
Code execution Speed (Rowley vs CC)
Started by ●May 25, 2008
Reply by ●May 26, 20082008-05-26
Reply by ●May 26, 20082008-05-26
Out of curiosity: why use volatile?
One of the C books that I read recommended to write
for(int c=0; c < 10; c++) {
; /* notice the semicolon */
}
for a delay loop. Is that still correct?
Thanks, Andreas
Paul Curtis:
> --- In m..., "John Heenan" wrote:
>
>> With the context reinserted, instead of removed to make spiteful
>> personal attack on me from some of the most boring, unimaginative,
>> spiteful and unemployable people on the planet, your compiler with
>> optimisation turned on is liable to turn, contrary to your
>> instructions
>> {
>> unsigned char x=0xFF;
>> while(xx--);
>> }
>> into absolutely nothing unless you use instead
>>
>> {
>> volatile unsigned char x=0xFF;
>> while(xx--);
>> }
>
> Your comments would be better directed to the ISO C working group
> as "guidance". Better still, refrain from snide comments that berate
> compilers which adhere to the standard as if they are beneath
> contempt in the transformations they correctly make.
>
> -- Paul.
>
One of the C books that I read recommended to write
for(int c=0; c < 10; c++) {
; /* notice the semicolon */
}
for a delay loop. Is that still correct?
Thanks, Andreas
Paul Curtis:
> --- In m..., "John Heenan" wrote:
>
>> With the context reinserted, instead of removed to make spiteful
>> personal attack on me from some of the most boring, unimaginative,
>> spiteful and unemployable people on the planet, your compiler with
>> optimisation turned on is liable to turn, contrary to your
>> instructions
>> {
>> unsigned char x=0xFF;
>> while(xx--);
>> }
>> into absolutely nothing unless you use instead
>>
>> {
>> volatile unsigned char x=0xFF;
>> while(xx--);
>> }
>
> Your comments would be better directed to the ISO C working group
> as "guidance". Better still, refrain from snide comments that berate
> compilers which adhere to the standard as if they are beneath
> contempt in the transformations they correctly make.
>
> -- Paul.
>
Reply by ●May 26, 20082008-05-26
--- In m..., Andreas Koepke wrote:
>
> Out of curiosity: why use volatile?
>
> One of the C books that I read recommended to write
>
> for(int c=0; c < 10; c++) {
> ; /* notice the semicolon */
> }
>
> for a delay loop. Is that still correct?
The semicolon has no effect, it delimits a null statement. The loop can be optimized away
completely. This is because c's scope is restricted to the for loop and, hence, its value is
dead at the end of the for loop. Because it is dead and not volatile, data flow and
dominator analysis reveals the code is dead. (Modern compilers use SSA or variants such
as GSA and this loop just washes away as a by-product of PRE.)
This is mildly technical for those that know nothing of compilers.
-- Paul.
>
> Out of curiosity: why use volatile?
>
> One of the C books that I read recommended to write
>
> for(int c=0; c < 10; c++) {
> ; /* notice the semicolon */
> }
>
> for a delay loop. Is that still correct?
The semicolon has no effect, it delimits a null statement. The loop can be optimized away
completely. This is because c's scope is restricted to the for loop and, hence, its value is
dead at the end of the for loop. Because it is dead and not volatile, data flow and
dominator analysis reveals the code is dead. (Modern compilers use SSA or variants such
as GSA and this loop just washes away as a by-product of PRE.)
This is mildly technical for those that know nothing of compilers.
-- Paul.
Reply by ●May 26, 20082008-05-26
On Mon, 26 May 2008 20:12:11 -0000, Paul wrote:
>--- In m..., Andreas Koepke wrote:
>>
>> Out of curiosity: why use volatile?
>>
>> One of the C books that I read recommended to write
>>
>> for(int c=0; c < 10; c++) {
>> ; /* notice the semicolon */
>> }
>>
>> for a delay loop. Is that still correct?
>
>The semicolon has no effect, it delimits a null statement. The loop can be optimized away
>completely. This is because c's scope is restricted to the for loop and, hence, its value is
>dead at the end of the for loop. Because it is dead and not volatile, data flow and
>dominator analysis reveals the code is dead. (Modern compilers use SSA or variants such
>as GSA and this loop just washes away as a by-product of PRE.)
>
>This is mildly technical for those that know nothing of compilers.
What's interesting to me is that programmers of C and C++ really do
need to understand some small amount of compiler practice and theory
in order to write correct code for intended purposes.
For those mildly interested, I found these quickly at Wiki:
http://en.wikipedia.org/wiki/Static_single_assignment_form
http://en.wikipedia.org/wiki/Partial_redundancy_elimination
http://en.wikipedia.org/wiki/Global_value_numbering
http://en.wikipedia.org/wiki/Common_subexpression_elimination
http://en.wikipedia.org/wiki/Loop-invariant_code_motion
http://en.wikipedia.org/wiki/Strength_reduction
Some of those are rather unsatisfying; none of them completely spell
out what Paul is on about in clear and precise detail; and I didn't
see anything there on the guarded form at Wiki, but it can be looked
up by googling "guarded single assignment form" if interested in more
of the details there.
Jon
>--- In m..., Andreas Koepke wrote:
>>
>> Out of curiosity: why use volatile?
>>
>> One of the C books that I read recommended to write
>>
>> for(int c=0; c < 10; c++) {
>> ; /* notice the semicolon */
>> }
>>
>> for a delay loop. Is that still correct?
>
>The semicolon has no effect, it delimits a null statement. The loop can be optimized away
>completely. This is because c's scope is restricted to the for loop and, hence, its value is
>dead at the end of the for loop. Because it is dead and not volatile, data flow and
>dominator analysis reveals the code is dead. (Modern compilers use SSA or variants such
>as GSA and this loop just washes away as a by-product of PRE.)
>
>This is mildly technical for those that know nothing of compilers.
What's interesting to me is that programmers of C and C++ really do
need to understand some small amount of compiler practice and theory
in order to write correct code for intended purposes.
For those mildly interested, I found these quickly at Wiki:
http://en.wikipedia.org/wiki/Static_single_assignment_form
http://en.wikipedia.org/wiki/Partial_redundancy_elimination
http://en.wikipedia.org/wiki/Global_value_numbering
http://en.wikipedia.org/wiki/Common_subexpression_elimination
http://en.wikipedia.org/wiki/Loop-invariant_code_motion
http://en.wikipedia.org/wiki/Strength_reduction
Some of those are rather unsatisfying; none of them completely spell
out what Paul is on about in clear and precise detail; and I didn't
see anything there on the guarded form at Wiki, but it can be looked
up by googling "guarded single assignment form" if interested in more
of the details there.
Jon
Reply by ●May 26, 20082008-05-26
On Mon, 26 May 2008 13:40:55 -0700, I wrote:
>On Mon, 26 May 2008 20:12:11 -0000, Paul wrote:
>
>>--- In m..., Andreas Koepke wrote:
>>>
>>> Out of curiosity: why use volatile?
>>>
>>> One of the C books that I read recommended to write
>>>
>>> for(int c=0; c < 10; c++) {
>>> ; /* notice the semicolon */
>>> }
>>>
>>> for a delay loop. Is that still correct?
>>
>>The semicolon has no effect, it delimits a null statement. The loop can be optimized away
>>completely. This is because c's scope is restricted to the for loop and, hence, its value is
>>dead at the end of the for loop. Because it is dead and not volatile, data flow and
>>dominator analysis reveals the code is dead. (Modern compilers use SSA or variants such
>>as GSA and this loop just washes away as a by-product of PRE.)
>>
>>This is mildly technical for those that know nothing of compilers.
>
>What's interesting to me is that programmers of C and C++ really do
>need to understand some small amount of compiler practice and theory
>in order to write correct code for intended purposes.
>
>For those mildly interested, I found these quickly at Wiki:
>
>http://en.wikipedia.org/wiki/Static_single_assignment_form
>http://en.wikipedia.org/wiki/Partial_redundancy_elimination
>http://en.wikipedia.org/wiki/Global_value_numbering
>http://en.wikipedia.org/wiki/Common_subexpression_elimination
>http://en.wikipedia.org/wiki/Loop-invariant_code_motion
>http://en.wikipedia.org/wiki/Strength_reduction
>
>Some of those are rather unsatisfying; none of them completely spell
>out what Paul is on about in clear and precise detail; and I didn't
>see anything there on the guarded form at Wiki, but it can be looked
>up by googling "guarded single assignment form" if interested in more
>of the details there.
>
>Jon
Or 'gated' rather than 'guarded.' That may be better.
Also see:
http://citeseer.ist.psu.edu/brandis94singlepas.html
Jon
>On Mon, 26 May 2008 20:12:11 -0000, Paul wrote:
>
>>--- In m..., Andreas Koepke wrote:
>>>
>>> Out of curiosity: why use volatile?
>>>
>>> One of the C books that I read recommended to write
>>>
>>> for(int c=0; c < 10; c++) {
>>> ; /* notice the semicolon */
>>> }
>>>
>>> for a delay loop. Is that still correct?
>>
>>The semicolon has no effect, it delimits a null statement. The loop can be optimized away
>>completely. This is because c's scope is restricted to the for loop and, hence, its value is
>>dead at the end of the for loop. Because it is dead and not volatile, data flow and
>>dominator analysis reveals the code is dead. (Modern compilers use SSA or variants such
>>as GSA and this loop just washes away as a by-product of PRE.)
>>
>>This is mildly technical for those that know nothing of compilers.
>
>What's interesting to me is that programmers of C and C++ really do
>need to understand some small amount of compiler practice and theory
>in order to write correct code for intended purposes.
>
>For those mildly interested, I found these quickly at Wiki:
>
>http://en.wikipedia.org/wiki/Static_single_assignment_form
>http://en.wikipedia.org/wiki/Partial_redundancy_elimination
>http://en.wikipedia.org/wiki/Global_value_numbering
>http://en.wikipedia.org/wiki/Common_subexpression_elimination
>http://en.wikipedia.org/wiki/Loop-invariant_code_motion
>http://en.wikipedia.org/wiki/Strength_reduction
>
>Some of those are rather unsatisfying; none of them completely spell
>out what Paul is on about in clear and precise detail; and I didn't
>see anything there on the guarded form at Wiki, but it can be looked
>up by googling "guarded single assignment form" if interested in more
>of the details there.
>
>Jon
Or 'gated' rather than 'guarded.' That may be better.
Also see:
http://citeseer.ist.psu.edu/brandis94singlepas.html
Jon
Reply by ●May 26, 20082008-05-26
On Mon, 26 May 2008 13:58:44 -0700, I wrote:
>Also see:
>
> http://citeseer.ist.psu.edu/brandis94singlepas.html
This one is helpful, besides having the Aho, Sethi, and Ullman book
from 1986, "Compilers principles, techniques, and tools" handy.
http://citeseer.ist.psu.edu/cytron91efficiently.html
Jon
>Also see:
>
> http://citeseer.ist.psu.edu/brandis94singlepas.html
This one is helpful, besides having the Aho, Sethi, and Ullman book
from 1986, "Compilers principles, techniques, and tools" handy.
http://citeseer.ist.psu.edu/cytron91efficiently.html
Jon
Reply by ●May 26, 20082008-05-26
On Mon, 26 May 2008 20:12:11 -0000, Paul wrote:
>This is mildly technical for those that know nothing of compilers.
This site may help a little:
http://www.cis.upenn.edu/~cis570/
http://www.cis.upenn.edu/~cis570/schedule.html
Jon
>This is mildly technical for those that know nothing of compilers.
This site may help a little:
http://www.cis.upenn.edu/~cis570/
http://www.cis.upenn.edu/~cis570/schedule.html
Jon
Reply by ●May 26, 20082008-05-26
--- In m..., Jon Kirwan wrote:
> What's interesting to me is that programmers of C and C++ really do
> need to understand some small amount of compiler practice and theory
> in order to write correct code for intended purposes.
Indeed. For those with a passing interest in this, Richard Bornat's free book is a good, but
dated, introduction. I count myself lucky to have it in paperback.
http://en.wikipedia.org/wiki/Richard_Bornat
Compiler technology marches on, and the Appel books are a great resource. I don't know
how he has the energy or drive to publish in three variants.
http://www.cs.princeton.edu/~appel/
The book I particularly enjoyed reading, possibly more than any other on compilers, is this
one. Why? Because rather than being an academic book (although packed with good
stuff), it is infused with advice from somebody that had to build a production optimizing
compiler for his day job. Documented, practical experience is well-worth reading.
http://www.amazon.com/Building-Optimizing-Compiler-Robert-
Morgan/dp/155558179X/ref=sr_1_3?ie=UTF8&s=books&qid11839496&sr=1-3
I have a huge number of books. Others that spring to mind as being pretty neat and not
rehashing the same old stuff are the Bulldog book (which I'm sure I've told Jon about
before) and this gem of a book:
http://www.amazon.com/Optimizing-Supercompilers-Supercomputers-Monographs-
Distributed/dp/0262730820
-- Paul.
> What's interesting to me is that programmers of C and C++ really do
> need to understand some small amount of compiler practice and theory
> in order to write correct code for intended purposes.
Indeed. For those with a passing interest in this, Richard Bornat's free book is a good, but
dated, introduction. I count myself lucky to have it in paperback.
http://en.wikipedia.org/wiki/Richard_Bornat
Compiler technology marches on, and the Appel books are a great resource. I don't know
how he has the energy or drive to publish in three variants.
http://www.cs.princeton.edu/~appel/
The book I particularly enjoyed reading, possibly more than any other on compilers, is this
one. Why? Because rather than being an academic book (although packed with good
stuff), it is infused with advice from somebody that had to build a production optimizing
compiler for his day job. Documented, practical experience is well-worth reading.
http://www.amazon.com/Building-Optimizing-Compiler-Robert-
Morgan/dp/155558179X/ref=sr_1_3?ie=UTF8&s=books&qid11839496&sr=1-3
I have a huge number of books. Others that spring to mind as being pretty neat and not
rehashing the same old stuff are the Bulldog book (which I'm sure I've told Jon about
before) and this gem of a book:
http://www.amazon.com/Optimizing-Supercompilers-Supercomputers-Monographs-
Distributed/dp/0262730820
-- Paul.
Reply by ●May 26, 20082008-05-26
On Mon, 26 May 2008 22:17:07 -0000, Paul wrote:
>Bulldog book
I have it on my shelf. Bought it when it came out, in fact, in the
middle 1980's around the time I got my 2nd edition of the dragon book,
I think. Ph.D. thesis, as I recall. Anyway, it's good. Read it
cover to cover.
Jon
>Bulldog book
I have it on my shelf. Bought it when it came out, in fact, in the
middle 1980's around the time I got my 2nd edition of the dragon book,
I think. Ph.D. thesis, as I recall. Anyway, it's good. Read it
cover to cover.
Jon
Reply by ●May 26, 20082008-05-26
On Mon, 26 May 2008 15:49:52 -0700, I wrote:
>On Mon, 26 May 2008 22:17:07 -0000, Paul wrote:
>
>>Bulldog book
>
>I have it on my shelf. Bought it when it came out, in fact, in the
>middle 1980's around the time I got my 2nd edition of the dragon book,
>I think. Ph.D. thesis, as I recall. Anyway, it's good. Read it
>cover to cover.
>
>Jon
It's where I learned the term "trace scheduling," I think, and looked
closely at the idea of scheduling instructions backwards across code
edges. There was a section on scheduling for banked DRAM memory, as I
recall and thoughts about supplementing language code with comments
that provide clues about the programmer's estimates of branch
probabilities (though much more has been done on run-time data
collection, since.) Keeping multiple functional units fed, on VLIW
machines, was an important focus of the book. MASSPAR, I think?
I need to pull the book and go back and refresh some of my own memory
on it, I suppose.
Jon
>On Mon, 26 May 2008 22:17:07 -0000, Paul wrote:
>
>>Bulldog book
>
>I have it on my shelf. Bought it when it came out, in fact, in the
>middle 1980's around the time I got my 2nd edition of the dragon book,
>I think. Ph.D. thesis, as I recall. Anyway, it's good. Read it
>cover to cover.
>
>Jon
It's where I learned the term "trace scheduling," I think, and looked
closely at the idea of scheduling instructions backwards across code
edges. There was a section on scheduling for banked DRAM memory, as I
recall and thoughts about supplementing language code with comments
that provide clues about the programmer's estimates of branch
probabilities (though much more has been done on run-time data
collection, since.) Keeping multiple functional units fed, on VLIW
machines, was an important focus of the book. MASSPAR, I think?
I need to pull the book and go back and refresh some of my own memory
on it, I suppose.
Jon
