> On Thursday 07 April 2005 19:09, David Schwartz wrote:

> > > Translation: The compiler can't make assumptions about the state of a
> > > variable marked "volatile", and MUST generate code that writes
> > > every result
> > > stored there as well as code that reads the variable EVERY
> > > SINGLE TIME it
> > > appears in an expression. It has nothing to do with multi-processor
> > > coherency. Any compiler that generates code that deviates from
> > > this (even a
> > > little bit) isn't compliant with the standard.

> > If this were true, every compiler I know of would fail to
> > comply with the
> > standard if it didn't bypass any write-back caches on writes to volatile
> > variables. After all, those "unknown factors" could modify the memory
> > directly, couldn't they?

> Nope. The compiler just has to store the variable at what it
> believes to be
> the correct address in memory (and fetch it from there, too)
> whenever there's
> a sequence point in the stream of execution that changes or accesses its
> value. It's up to the system as a whole to translate the address into
> storage - main, cache, or completely virtual.

No. The C standard is not telling the compiler what to do. It is saying
what the system must do when it runs the particular source code. If the
compiler cannot generate code that makes the system as a whole comply with
the standard, then the compiler does not conform.

> int a;
> int c;
> void foo(int b)
> {
> c = b;
> a = c;
> }

> into an assembly language sequence that loads the contents of b into a
> register, and then stores it into both a and c. The following code:

> int a;
> volatile int c;
> void foo(int b)
> {
> c = b;
> a = c;
> }

> would require that the compiler generate code that stores the
> value of b into
> c, and then stores the value in c into a. While the compiler
> would have to
> take write reordering into account with respect to this
> particular process
> (or it would violate the requirement that c be written before it's read
> again), it's free to ignore caching. It's also free to ignore write
> reordering with respect to other processes.

The compiler is not free to ignore anything. If the C standard specifies
that the writes must occur in order, then the compiler must make the writes
occur in order. Not generate assembly code that makes it look like the
writes occur in order, but occur in order. The abstract machine is not about
assembly language, itís about what actually happens.

> > However, your translation is incorrect. The standard is not
> > talking about
> > the compiler, but the system as a whole. It is not saying what
> > the compiler
> > must do but what the compiler must emit code to make the system
> > as a whole
> > do.

Please read this over a few times and think about it.

> > The reason this doesn't require write-back caches to be disabled is
> > because the abstract machine doesn't make it clear where the
> > object is. Is
> > the object the physical memory chips? The memory as seen
> > through the cache?
> > Or what?

> Again, I never said anything about caching, since caching is a
> system feature
> that is either transparent (ie - it "just works"), or it requires special
> coding techniques that are well beyond the scope of any general language
> specification.

Thatís the thing. If the C standard requires the writes to occur in order,
then any compiler that was conformant on systems with caching would have to
make sure the writes occured in order.

The C standard does not distinguish between before or after caching, and
you canít just randomly pick a point and say thatís what the standard means.


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org