From mboxrd@z Thu Jan  1 00:00:00 1970
To: 9fans@cse.psu.edu
From: "Douglas A. Gwyn" <DAGwyn@null.net>
Message-ID: <3DD47620.6040909@null.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
References: <9f877f9ea3f57d8602e66baf3ce1988a@plan9.bell-labs.com>
Subject: Re: [9fans] how to avoid a memset() optimization
Date: Fri, 15 Nov 2002 10:51:16 +0000
Topicbox-Message-UUID: 2138b978-eacb-11e9-9e20-41e7f4b1d025

Dennis Ritchie wrote:
> This wasn't true for the PDP-11 compiler, which
> (approximately) treated everything as volatile in the
> current sense, though it could do some elementary
> dead-code elimination.  The (early) BSD/VAX assembly
> optimizer did have something like this, however, in that it
> avoided certain instructions that wouldn't work in the I/O
> space.

Thanks for the correction.  I was told about it by people
who worked on the PCC/QCC/RCC etc. family in general, and
from the description I thought they meant the PDP-11;
of course the VAX-11 had a very similar I/O interface.
Regardless, the PDP-11 even with its relatively direct
mapping of C into instructions still required careful
fiddling in the source code for some device drivers in
order to avoid read-modify-write cycles etc. -- stuff
that is clearly beyond the scope of what could be
controlled with a single keyword, much less what could
be gotten "right" in every case with no work for the
programmer.

 > The intent of volatile was to capture appropriate
 > behavior of memory-mapped registers and similar
 > things (like a clock in user space updated by the
 > OS.)  So, things like
 > 	*p = 0;
 > 	*p = 0;
 > should generate two stores if p is volatile *int.

Yes, the C standard requires that, with the correction
that it is the int that must be volatile-qualified,
not the pointer.  I.e., volatile int* if we're using C
abstract types.  It is still up to the implementation
to determine whether the store involves a read also
and how wide the access is (e.g., if int is 32 bits on
a 64-bit word bus, the store would necessitate fetch
of 64 bits, modification of 32 of them, and write-back
of 64 bits).  There doesn't seem to be any point in
trying to let the programmer specify such details,
since they're normally built into the hardware.  But
volatile as it is specified at least lets the programmer
control the *compiler* (code generator), which is
partial control and quite often good enough.