Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!amdcad!light!bvs
From: bvs@light.uucp (Bakul Shah)
Newsgroups: comp.std.c
Subject: Observability (was Re: Semi constant expressions)
Message-ID: <1989Sep7.211159.7124@light.uucp>
Date: 7 Sep 89 21:11:56 GMT
References: <1989Sep6.160709.4890@light.uucp> <10962@smoke.BRL.MIL>
Reply-To: bvs@light.UUCP (Bakul Shah)
Organization: -
Lines: 50

In article <10962@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>In article <1989Sep6.160709.4890@light.uucp> bvs@light.UUCP (Bakul Shah) writes:
>>I have some questions about `observable behavior'.  How does this
>>concept interact with `volatile' variables? with debuggers? with
>>shared memory?
>
>"Observable behavior" was my own terminology.  The proposed Standard
>doesn't go into this in great detail.

I am glad you used that term as `observability' very nicely captures
the semantics of volatile objects, modifying files etc.  Observability
is important but not necessarily obvious to many.  One reason I wanted
some discussion was because the pANS doesn't say much about it.

>I believe the constraints on volatile variables are sufficient to
>ensure that accesses really do occur according to the abstract
>machine.  There is a bit of deliberate vagueness about the atomicity
>of the access.

Well, using observability as an explicit guiding principle this
vagueness could have been tightened some more.  For instance, one can
say that each time a volatile object is referenced at source level for
reading/writing, _atleast_ one access of the appropriate kind is made.
If you are willing to admit existence of a minumum size object that
can be changed all at once, one more guarantee can be made (to the
memory mapped IO crowd): assigning to this object will not result in a
read access.  The last makes sense because the effect is observable
and yet, the compiler need not know why.

>Debugging environments are beyond the scope of the Standard.
>How useful yours is depends on the care put into it by the vendor.
> ...
>
>Generally, it would be too hard for a compiler to perform the analysis
>necessary to determine how much code generation could be omitted due
>to its having no observable effect.  Some local optimizations are
>expected, but without a very smart compiler the only safe thing would
>be for it to ensure that side effects have code executed to cause them.

There are compilers that throw out things even when -g is specified
and rearrange code in their zeal to be the fastest.  When it comes to
optimization most compilers either stick to safe optimizations or do
some questionable ones.  In both cases observability can be used to
separate what is doable from what is not.

I realize that debugging environments and such are beyond the scope of
the pANS which why such guidelines can be very useful (may be as part
of the Rationale).

-- Bakul Shah <..!{ames,sun,ucbvax,uunet}!amdcad!light!bvs>