Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.std.c
Subject: Re: Semi constant expressions
Keywords: observability, volatility, debugging, shared memory, Zen
Message-ID: <10962@smoke.BRL.MIL>
Date: 7 Sep 89 04:37:27 GMT
References: <1237@gmdzi.UUCP> <10885@smoke.BRL.MIL> <242@ssp1.idca.tds.philips.nl> <10937@smoke.BRL.MIL> <1989Sep6.160709.4890@light.uucp>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 41

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.  It does mention output of a
strictly conforming program, acceptance of a program by the
implementation, accessing volatile objects, and modifying files.
Section 2.1.2.3 contains the main relevant constraints, e.g. the
implementation must ensure that at program termination all data
written into files be identical with that which would have resulted
according to the abstract machine's semantics.

>Are volatile variables considered to be observable within their
>scope at all times (or at sequence points)?  Is this mechanism
>sufficient for indicating that an object is observable?

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.

>While debugging a piece of code I may want everything accessed from
>it to be observable.  Should a compiler treat such variables as
>volatile?

Debugging environments are beyond the scope of the Standard.
How useful yours is depends on the care put into it by the vendor.

>Is a program with *no* output of any kind observable?

My interpretation is that a purely computational process could be
optimized into a no-op and meet the constraints of the Standard.
Undoubtedly some vendors will do just that for common benchmarks!

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.