volatile

[Every system needs one]

In article <51431 at sun.uucp>, limes at sun.uucp (Greg Limes) writes:
> In article <502 at wsccs.UUCP> terry at wsccs.UUCP (Every system needs one) writes:
> [previous junk removed for brevity]
> >	Yes, but why is
> >		volitile int foo;
> >	better than
> >		int foo;	/* VOLITILE*/
> >	Except for the optimizer?
> 
> The first not only documents for the user that "foo" may be changed
> outside the expected flow of control of the program (i.e. by hardware
> or by a signal handler), but making it a part of the language forces
> optimiser designers to leave open this trapdoor.

If you are implying that the compiler writer would have to write code to
make valid assumptions before optimizing, my heart bleeds.

> It also standardises
> where they will put the trapdoor, if/when they realize that programmers
> need to be able to break out of the dreaded
> 	while (!signal_caught);
> loops ... try running the previous line through the SunOS 4.0 compiler
> at any optimisation level higher than about, say, -O1 ...

I have grave reservations about the compiler you mentioned anyway.

All I'm saying, again and again and again, is that the compiler writer, not
the compiler user should bear the burden of matching the language to the
architecture.  I have agreed before that volitile is OK for DMA where the
user prefers to use a buzz-loop instead of an interrupt.  Say a message
passing operating system.

The whole direction of the argument has been changed, now, I hope.  The
question, bluntly, is:

	Why can't the compiler figure out what is volitile and
	THEN optimize without being hit over the head?  Is this
	a matter of it being impossible, or are the compiler
	writers pushing the responsibilty onto the user without
	justification?  If it can be done by the compiler with
	more work on the compiler-writer's part, is the increased
	time worth it, in light of the coding time it would save
	[hypothetically] for the compiler user?  Who's time is
	more important?

I vote pro user.  The "better except for the optimzer" referred to the
optimizer having to work harder, NOT to optimizations being impossible
without "volitile".  I don't believe in impossible; just very very hard
and requiring intelligent thought.

> Compiler technology is getting really good, and we need a way to tell
> the optimisers that strange things can happen.

If it's sooooo advanced, it could determine volatility (or aliasing)
without me having to tell it.  This is my entire point.  If it isn't
that advanced, it should either quit pretending or be fixed.


| 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 just harrasing me because of the quote in my signature!' |