Richard Salz wrote:
This is the precise optimization that 'volatile' inhibits. 'volatile'
requires that the value not be cached in "cheap-to-access" locations
like registers, instead being re-loaded from "expensive-to-access"
locations like the original memory -- because it may be changed from
outside the control flow that the compiler knows about.
Agreed with the sorts of things volatile inhibits.
You are both wrong.
Just to clarify what exactly your comment is aimed at. Is it still on
the tangent subject of volatile usage ? or is this in relation to the
original poster subject matter ?
If its the meaning of volatile, I used the term "sorts of" to be
deliberately vague to mean that Kyle is in the right ball park (which he
is even under your double *p++ *p++ example I can relate that to what
Kyle wrote above) and as it is a tangent subject the main point of my
comment was to close the tangent down; so thats that on volatile usage
from me.
However if your comment is addressed at the more useful part of my
replies (the bit you didn't quote) then I am definitely interested if
you would elaborate on that.
The C standard is *silent* on the concept of underlying hardware. It only
talks about the flow of control as defined in the module being translated.
It created a new term, sequence point, to talk about control flow in an
abstract way.
I can't actually relate that comment to either discussion. No one is
disputing the definition of "flow control". No one is claiming that the
"C standard" defines anything at the hardware layer. When the hardware
layer has been talked about it was either cited as an example of usage
(not cited as the definition); or it was talked about in relation to
what a compiler does and does not do when it generates assembly language
instructions.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
