volatile inhibits side-effects

[Mantorok Redgormor]

does volatile really inhibit side effects?
that is the rules for sequence points and side effects do not apply to
volatile objects?

 

[Mike Wahler]

does volatile really inhibit side effects?

No. Where did you hear that?

that is the rules for sequence points and side effects do not apply to
volatile objects?

No. Where did you hear that?

'volatile' is intended for preventing possible compiler
optimization, so that a 'volatile' qualified object can
acquire a state from an external source without the compiler
'optimizing it away'.

-Mike

 

[Mantorok Redgormor]

No. Where did you hear that?


No. Where did you hear that?

'volatile' is intended for preventing possible compiler
optimization, so that a 'volatile' qualified object can
acquire a state from an external source without the compiler
'optimizing it away'.

-Mike

6.7.3#6
An object that has volatile-qualified type may be modified in ways unknown
to the implementation or have other unknown side effects.

wouldn't this mean that an object which is volatile could even be modified
between sequence points?

 

[Mike Wahler]

"Mike Wahler" <[email protected]> wrote in message

6.7.3#6
An object that has volatile-qualified type may be modified in ways unknown
to the implementation or have other unknown side effects.

Right. But the use of the term 'side effect' here is not
what I 'traditionally' think of as 'side effect', i.e.
an executable construct such as obj++. Sorry for any
confusion.

wouldn't this mean that an object which is volatile could even be modified
between sequence points?

Yes, I suppose so, but I wouldn't testify to it in court.
Let's see if some 'guru' will respond more definitively.

-Mike

 

[Kevin Goodsell]

6.7.3#6
An object that has volatile-qualified type may be modified in ways unknown
to the implementation or have other unknown side effects.

wouldn't this mean that an object which is volatile could even be modified
between sequence points?

Yes, but the statements in your first post don't follow from that. It's
not clear to me why you would conclude from the passage above that
'volatile' inhibits side-effects. Actually, it's not clear to me what
you mean by "inhibits side-effects", either.

The passage above is for situations such as memory-mapped I/O, when the
value at a particular memory location can change from one read to the
next, for example:

volatile char *vp = (char *)0x802a0010; /* Some device or port address */

char c1, c2;

c1 = *vp;
c2 = *vp;

Normally this could be optimized to something like this:

Get value from address vp, store in register A.
Store value from register A in c1.
Store value from register A in c2.

Because the compiler would normally assume that *vp cannot change unless
it emits code to change it. But since *vp is volatile, the compiler does
not make this assumption, and emits code to actually do two separate reads:

Get value from address vp, store in register A.
Store value from register A in c1.
Get value from address vp, store in register B.
Store value from register B in c2.

While I'm talking specifically about reading volatile objects, the write
situation is analogous. E.g., if you were to write to an object twice
without any kind of read in between, the compiler could assume the first
write is useless and eliminate it, but if the object is volatile, the
compiler won't make that assumption.

-Kevin

 

[Mac]

6.7.3#6
An object that has volatile-qualified type may be modified in ways unknown
to the implementation or have other unknown side effects.

wouldn't this mean that an object which is volatile could even be modified
between sequence points?

Yes, but not by you, the programmer. My understanding of volatile is that
it is principally used when a hardware mechanism exists that can change
the data without the compiler knowing about it. In a way, it is wrong to
think in terms of sequence points, since the modification, if any, could
happen any time (in principal). It is completely outside the sequence
point frame of reference.

I don't see how this removes the requirement that you refrain from
modifying a variable twice between sequency points, etc.

Mac
--

 

[Sheldon Simms]

6.7.3#6
An object that has volatile-qualified type may be modified in ways unknown
to the implementation or have other unknown side effects.

wouldn't this mean that an object which is volatile could even be modified
between sequence points?

I think you are reading this "backward". The standard is not trying to say
that if you declare a variable volatile, then the implementation is free
to change the variable whenever it wants to.

The point of volatile is that you, the programmer, use volatile to tell
the implementation that the value of the object can be changed "behind the
implementation's back".

The result of this is that when you declare an object volatile, the
implementation can not assume that it "knows" the value of the object.
Every time the object is referenced in your program, the implementation
must check the object to see if the value has changed. This prevents the
implementation from optimizing accesses to the variable by, for example,
keeping the value of the variable in a register. The implementation must
reload the value of the object every time it is referenced in the program.

 

[glen herrmannsfeldt]

Mantorok Redgormor wrote:

6.7.3#6
An object that has volatile-qualified type may be modified in ways unknown
to the implementation or have other unknown side effects.

wouldn't this mean that an object which is volatile could even be modified
between sequence points?

PL/I has a similar attribute called ABNORMAL. One explanation I saw for
it said that for a statement such as J=I*I; the value of I should be
fetched from memory twice.

In C, it is sometimes used for memory mapped I/O devices, where each
load might return a different value. Consider a memory mapped hardware
random number generator, for example.

-- glen

 

[Dan Pop]

Yes, but not by you, the programmer. My understanding of volatile is that
it is principally used when a hardware mechanism exists that can change
the data without the compiler knowing about it.

It need not be a hardware mechanism, there is also a software mechanism
that can do that: it's called signal handler.

Dan

 

[Michael Steve]

Volatile variables are useful in AST, thread, and shared memory programming.
Of course, if the variable manipulations are not atomic (which I may be
misinterpreting as your concept of modification between sequence points)
then other concepts, such as locking, become necessary (if allowable).

Volatile is a step towards opening a Pandoras box on Programming concepts
that can cause great headaches.

~~~^~~^~~^~~^~~^~~^^^~~~~^^~
Michael Steve
To err is human, to really screw something up requires a manager.

 

[glen herrmannsfeldt]

Dan Pop wrote:

(after someone wrote)

It need not be a hardware mechanism, there is also a software mechanism
that can do that: it's called signal handler.

Well, yes, but a signal handler won't be invoked without a signal, which
usually requires some hardware.

-- glen

 

[Irrwahn Grausewitz]

Dan Pop wrote:

(after someone wrote)


Well, yes, but a signal handler won't be invoked without a signal, which
usually requires some hardware.

A signal may well be generated by invocation of the raise() function.

Regards

 

[Dan Pop]

Dan Pop wrote:

(after someone wrote)


Well, yes, but a signal handler won't be invoked without a signal, which
usually requires some hardware.

Running the program requires some hardware in the first place. Most
standard signals don't require any additional hardware: SIGABRT,
SIGFPE, SIGILL, SIGSEGV, SIGTERM. It's only SIGINT that is typically
(but not necessarily) associated with the presence of a keyboard.

Dan

 

[Mac]

It need not be a hardware mechanism, there is also a software mechanism
that can do that: it's called signal handler.

Dan

Thanks. I hadn't thought of that (obviously).

Mac
--