Optimization, volatile (was Re: volatile)

[Every system needs one]

In article <2003 at rtech.UUCP>, jas at llama.rtech.UUCP (Jim Shankland) writes:
> In article <13074 at brl-adm.ARPA> dsill at NSWC-OAS.arpa (Dave Sill) writes:
> >I (Terry) write:
> >>Basically, if it works without -O, it should work with -O, regardless of what
> >>the compiler writer's optimization does to achieve its goal.  If this makes
> >>writing compilers harder, so what?
> >
> >This bears repeating.  There should be no circumstances under which
> >the semantics of the language are changed by a flag to the compiler.
> 
> However, you didn't repeat it.  Your assertion is reasonable, Lambert's
> is not.  The world is full of (strictly speaking) incorrect C programs
> that work just fine because of some accident of hardware, the compiler
> used, etc.

Well, before you rip my head off for a fragment (strictly speaking out of
context), consider it a basic assumption that you are compiling good code.
Further assume that the standard is K&R, not ANSI.  Keeping badly written
programs running on a single architecture was not the object of my statement;
I have clarified this in another posting this very evening.  I don't expect
non K&R-conforming programs to work.

> A good optimizer can "break" programs (actually, cause existing bugs to
> become manifest)

It shouldn't be necessary to change all the code in the world to be ANSI
conformant (instead of K&R conformant) to keep some stupid optimizer from
breaking it.

> just as porting a C program from a VAX to a Sun can.

This is the method one should use to determine if code is "bad"... but I
suggest you do not use a SUN 400* (matches all SUN 400 series) as your Sun,
as some of the assumptions it makes are _NOT_ K&R.

> Perhaps that sounds like nitpicking; I don't think it is.  To get back
> to "volatile":  it provides a portable way to declare storage objects
> that may change without notice, and thus is useful in writing portable
> (not necessarily portable *everywhere*, but plenty portable for may uses)
> programs that access device registers, use shared memory, signal handlers,
> etc. (we've been over the whole list).

yes, it's a nice toy on rare ocassion, but that's why #pragma was invented.

> 	I am amused to think what my employer's customers might say if
> 	we told them that we could have easily made our software 20-30%
> 	faster, but couldn't be bothered for such an inconsequential gain.

	A: Don't tell them and keep your job.

> 	(3) "Let implementers of optimizing compilers come up with their
> 	own pragmas that can turn off certain optimizations where they
> 	will be destructive."  In other words, let each implementer
> 	add "volatile" in her own way.  However, the semantics of
> 	"volatile" are well-defined and broadly useful.  Making its
> 	use non-portable is gratuitous.

This is silly.  If ANSI thinks they can redefine C, why should #pragma be
an effort in imagination?  Couldn't they say 'hey... use this'?

>	As an aside, the arguments over "volatile int mutex; ... ++mutex;"
>	are a red herring.  "volatile" clearly does not guarantee atomicity,
>	nor is it intended to.

No, but it might be an incentive to have it as a language feature instead of a
#dogma... Nope, doesn't swing me.


| 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...   |
| 'Admit it! you're harrasing me because of the quote in my signature!'       |