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