> On Thursday 07 April 2005 16:39, David Schwartz wrote:
> A bit off-topic, but...

> > If you mean 'volatile', no, that doesn't do anything. Specifically,
> > 'volatile' has no special semantics for multi-processors. There may be
> > specific compilers where it has such semantics, but the standard doesn't
> > provide them.

> According to ISO 9899-1990, section 6.5.3:

> An object that has volatile-qualified type may be modified in
> ways unknown to
> the implementation or have other unknown side effects. Therefore any
> expression referring to such an object shall be evaluated
> strictly according
> to the rules of the abstract machine, as described in
> Furthermore,
> at every sequence point the value last stored in the object shall
> agree with
> that prescribed by the abstract machine, EXCEPT AS MODIFIED BY

> 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?

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

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


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