volatile

Every system needs one terry at wsccs.UUCP
Thu Apr 28 14:06:51 AEST 1988


In article <20345 at pyramid.pyramid.com>, eric at pyrps5 (Eric Bergan) writes:
> In article <488 at wsccs.UUCP>, I write:
> > 
> > Machine dependancy is the responsibility of the compiler writer. 
> > Optimization is the responsibility of the compiler writer.
> > If architectural differences prevent effective use of the compiler, this is
> > the responsibility of the compiler writer.
> 
> 	I agree with these, but does this imply:
> 
> If language deficiencies prevent effective optimization, scrap the 
> optimizations?

	Yes, or rewrite them.

> "volatile" not only helps the optimizer, I would suggest it also helps
> document what is going on.

	Yes, but why is

		volitile int foo;

	better than

		int foo;	/* VOLITILE*/

	Except for the optimizer?

> 	The flip side of the argument is "How far should we bend C for
> optimization purposes?" [..."optimizing"...] But even then, there
  ^^^^^^^^^^^^^^^^^^^^^^ exactly!
> is simply too much pointer use going on to expect the average software
> house to rewrite all their code using either an "alias" or a
> "noalias".

Yes.

> (Note that the use of "volatile" is much less frequent, so
> the pain of converting to that is much less. Also, aggresive optimizers
> are already causing developers using volatile variables problems.)

I'll agree with this one because of the also, but it makes my teeth itch :-).

> I'd like to point out that as the hardware continues to get faster (and
> rely more heavily on register access, or keeping pipelines running), the
> optimizer must get more sophisticated to take advantage of that hardware,
> otherwise no performance improvement will be seen.

I have some questions as to weather or not hardware that gives you the choice
of fast or source code compatible (like SPARC) by requiring more instructions
be generated to implement code "the way God meant it to be" is actually
"faster" than hardware that uses less  but "slower" instructions.  But that
belongs in comp.arch, not here.  The problem is that the .arch seems to be going
off and tromping on my .lang.c... there should be dichotomy.


| Terry Lambert           UUCP: ...{ decvax, ihnp4 } ...utah-cs!century!terry |
| @ Century Software        OR: ...utah-cs!uplherc!sp7040!obie!wsccs!terry    |
| SLC, Utah                                                                   |
|                   These opinions are not my companies, but if you find them |
|                   useful, send a $20.00 donation to Brisbane Australia...   |
| 'There are monkey boys in the facility.  Do not be alarmed; you are secure' |



More information about the Comp.lang.c mailing list