> On Fri, 8 Apr 2005, David Schwartz wrote:
> > 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.
> Yes, but the standard is only defined in terms of what is visisble from a
> single thread, and not in terms of what is visible from external vantage
> points (like other threads).
Right.
> No C compiler I ever worked with issued the memory barrier/cache flush
> instructions needed to enforce cache behavior for volatile references.
> Specially, neither Visual Studio nor GCC for the x86 issues those
> sorts of
> instructions.
Right, and the standard doesn’t require them to. Nor does it require
them
to perform the operations in order as seen by another processor.
> This is actually pretty standard behavior in the face of caches,
> and write
> combining and speculative execution and all the other tricks modern CPUs
> are doing. It issued the write, and then issued a seperate read to read
> the value back in, and the fact that the CPU short circuited this isn't
> the compiler's problem. You can argue to the cows come home wether this
> is conformant or not- but that's the behavior on the ground.
I am arguing that it *is* conformant. The C standard is being misread in
this case, and that a consistent misreading would require that caches be
disabled. However, it’s being misread inconsistently. ;)
> > 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.
> That's what the compilers do. And if the machine combines the writes- as
> most modern CPUs almost certainly would, the compilers will not issue
> extra instructions to overcome this. Especially considering that it's
> non-trivial to determine if the extra instructions are even needed. I
> mean, on the x86 you have the CD and NW flags in CR0, you have the MTRRs,
> plus bit 6 of the IA32_MISC_ENABLE MSR all statically controlling various
> types of caching.
Right, and I’m arguing not that the compilers aren’t conforming but that
the standard is being misread. What I’m specifically arguing against is the
view that the standard says what the compiler must do and then the hardware
is free to do something different.
The C standard’s attempt to define accesses to volatile variables as
observable behavior is simply meaningless because what that would mean
varies dramatically based upon where you are supposed to observe the
behavior from, and the abstract machine contains no such observation points.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
