volatile isn't necessary, but it's there

[Eric S. Raymond]

In article <7794 at alice.UUCP>, dmr at alice.UUCP writes:
>It seems just as reasonable for purveyors of optimizing compilers for machines
>with memory-mapped IO to have a compiler flag that says "please
>be cautious about cacheing things in this routine."

I see your point, but I think the alternative you're proposing is ugly,
because it creates a kind of constraint on module organization that wasn't
there before and has nothing to do with what module structure ought to be
about (clean interfaces and data hiding).

>Alternatively, they could accept a #pragma in the code.

This is the alternative I'd favor. I think X3J11 should have a class of
'required' pragmas to do such optimization hinting.

>There is a real cost in having the feature in the language.

While I agree with your keep-it-simple philosophy in general, I think I
disagree with your implication here. I don't think C is a language for
novices; the issue, to me, is whether volatile complicates C to the
point where a skilled, multi-language programmer can no longer hold
the entire C language model in his head. I don't think volatile does
that, though it skates close.

(Note that I'm not insisting that all languages, or even all C-like
languages, should be small in this sense -- as an abstract-data-type-design
enthusiast I'm itching to get my hands on C++, which has *certainly* passed
that limit. But smallness in this sense is one of C's major strengths and
ought to be preserved by anything claiming to be a C standard)

>(I'm especially amused by some of the more extreme positions
>stated in favor of `volatile.'  May I be permitted to assert
>that it is possible to write a successful operating system
>without `volatile,' even on machines with memory-mapped IO?)

FWOOOM! *Someone* just got very politely flamed off above the ankles. :-) :-)
I succumbed to helpless giggles for a few minutes after first reading this...

>This is just a botch; the committee should have insisted
>that, if necessary, the compiler recognize setjmp and handle its caller
>specially.

O.K., I can sure agree with this. Is there any hope volatile can be
strengthened this way? At least maybe we should push correct longjmp
behavior as a named common extension and recommended behavior, so that
compiler implementers are put on notice that it is the Right Thing.

>The third hope for volatile, namely shared memory, is in some ways the
>most interesting because it nibbles at the edge of mechanisms
>that will become more important in the future.  Nevertheless,
>as several have pointed out, the Standard conspicuously avoids
>the extensions needed to make shared memory work
>(e.g. semaphores).

Well...yes. Semaphore implementation is sufficiently hardware-dependent
that they really have to be considered outside the purview of a language
definition (after all, if you don't have an atomic test-and-set instruction
at some level, you lose).

I'm afraid I don't see how this connects with the ill-definedness of volatile
on shared memory. After all, if increment to a memory location is atomic,
'volatile murex; murex++' has semantics that are meaningful and useful without
giving you the strict atomic-test guarantee that full semaphores would.

>Has anyone else noticed that a lot of the more peculiar things that X3J11
>has added (volatile, and especially noalias) are there for the
>benefit of compiler writers and benchmarkers, and not for the user?

Yeah. Maybe we should form our own analogue of Vietnam Veterans Against The
War; Compiler Hacks Against Compiler-hack Elitism.
-- 
      Eric S. Raymond                     (the mad mastermind of TMN-Netnews)
      UUCP: {{uunet,rutgers,ihnp4}!cbmvax,rutgers!vu-vlsi}!snark!eric
      Post: 22 South Warren Avenue, Malvern, PA 19355   Phone: (215)-296-5718