Re: const and static (was: C vs. assembly...)

cdg@nullstone.com (Christopher Glaeser)
27 Mar 1996 00:15:23 -0500

          From comp.compilers

Related articles
C code .vs. Assembly code for Microcontrollers/DSPs ? ravindra@hal.com (1996-03-01)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? sberg@camtronics.com (1996-03-14)
Re: C code .vs. Assembly code for Microcontrollers/DSPs ? cdg@nullstone.com (1996-03-16)
const and static (was: C vs. assembly...) mark@omnifest.uwm.edu (1996-03-25)
const and static (was: C vs. assembly...) fjh@cs.mu.OZ.AU (1996-03-27)
Re: const and static (was: C vs. assembly...) cdg@nullstone.com (1996-03-27)
Re: const and static (was: C vs. assembly...) mason@ease.com (1996-03-29)
Re: const and static (was: C vs. assembly...) cdg@nullstone.com (1996-04-02)
Re: const and static (was: C vs. assembly...) jmccarty@sun1307.spd.dsccc.com (1996-04-02)
Re: const and static (was: C vs. assembly...) KingD@rnd1.indy.tce.com (King Dale) (1996-04-11)
Re: const and static (was: C vs. assembly...) cdg@nullstone.com (1996-04-12)
Re: const and static (was: C vs. assembly...) cdg@nullstone.com (1996-04-12)
[3 later articles]
| List of all articles for this month |

From: cdg@nullstone.com (Christopher Glaeser)
Newsgroups: comp.compilers
Date: 27 Mar 1996 00:15:23 -0500
Organization: Compilers Central
References: 96-03-106 96-03-006 96-03-091 96-03-181
Keywords: C, optimize, performance

> int f_()
> {
> static integer i;
>
> for (i = 1; i <= 100; ++i) { }
> return 0;
> }


Mark Hopkins <mark@omnifest.uwm.edu> writes:
> A decent compiler should optimize this to
>
> int f_() { return 0; }


Agreed, but the loop body was not the point of this discussion. The
code fragments in this example were merely to illustrate that f2c maps
FORTRAN loop control variables to storage class static int, and
futhermore, that many compilers generate code several times slower for
loops with static loop control variables.


> However, I agree with you on the "const" feature -- but for different
> reasons. Not only should the compilers be using the "const" feature,
> but it shouldn't even have to have it because it should already be
> doing expression evaluations to reduce all those expressions that can
> be reduced at compile-time.
>
> In the example you cite:
> > #define ONE 1
> > const int one = 1;
> >
> > int f()
> > {
> > x = ONE;
> > y = one;
> > }
>
> this should compile to exactly the same thing as the following does:
>
> int f() { x = 1; y = 1; }


Yes, that's precisely the point. There's no disagreement here.


> I'd even go so far as to call it a hidden bug in the compiler if it
> didn't, the Standard notwithstanding.


Compilers are not required to perform this optimization, though some
programmers clearly have this expectation, as evidenced by your
comments.


> I actually do use const and enum (and bit fields) in place of #define
> with this understanding in mind.


Your understanding may or may not be correct, and you may want to
verify the output of your compiler. Some compilers perform this
optimization. Currently, the majority of C compilers do not.


Regards,
Christopher Glaeser cdg@nullstone.com
Nullstone Corporation http://www.nullstone.com
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.