You are arguing that it is implementation-defined whether a C compiler performs side-effects while evaluating an expression. I’ll first try to show you that this interpretation does not make sense, and second back this up using the standard.

You are arguing that when a C implementation evaluates an expression like this:

x;

(where x is volatile), the implementation is not required to perform the volatile access. Let us look at a different expression:

1+printf(“hello”);

You are arguing that the compiler does not need to print anything when evaluating this expression. Clearly this is wrong.

Next let’s look at the standard. I’m using N1425. You are interpreting “may” as “evaluation of a side-effecting expression (in the abstract machine) may or may not produce side effects in the actual computation.” This seems to be a misreading. I read it as “evaluating some expressions (like the examples above) produces side effects, whereas other expressions have no side effects.”

If you look at the standard you’ll see that “shall” and “shall not” have a codified meaning, whereas “may” does not. It is plain English. For example the standard says “Attention is drawn to the possibility that some of the elements of this document MAY be the subject of patent rights.” Clearly this is a plain English “may” and not some codified requirement about a C implementation.

If I haven’t convinced you, let me know, and we can continue to argue. However, since your interpretation leads to a useless language I cannot see how it could be a valid reading of the standard.

In ISO C 9899:1999 5.1.2.3 “Program execution” we can read that accessing a volatile object is a “side effect” and that “Evaluation of an expression may produce side effects”.

It says “may” and not “shall”.

Then in 6.8.3 “Expression and null statements” we can read that an expression is evaluated for its side effects, although the result is ignored (void expression).

So the expression will be -evaluated- but there is no guarantee for side effects, i.e actual access of the volatile. So I don’t think the C standard is “unambiguous”, on the contrary I think the standard is pretty clear that this is implementation-defined behavior. Feel free to cite the standard to prove me wrong.

—

For your information, I tested cload_reg1() and cload_reg2() on:
Freescale Codewarrior 4.7 for HCS12
Freescale Codewarrior 6.0 for HCS08.

- Optimization was enabled in both cases.
- On both compilers code is generated to access the variable.
- On both compilers I get a warning for “result not used”.

Because the premise:

” The operation that turns into a load instruction in the executable code is what the C++ standard calls
the lvalue-to-rvalue conversion;… ”

does not apply to the context:

“volatile”

since “volatile” values NEVER convert to rvalues:

” an rvalue (or just value; something whose address can’t be taken and can be in a register) ”

The disconnect seems to occur at the phrase

” can be in a register ”

which is of course still true for volatile values,
but misleading, because the (missing?) phrase

” can be cached in a register ”

is true for rvalues, but false for volatile values.

Therefore, the spec is apparently silent
on the issue of LOADing volatile values.

That said, if I were talking to volatile registers,
I’d be inclined to consider the C spec in error.

I might have tried something like:

void cload_reg (void)
{
register unsigned char sink;
sink = SBUF;
}

expecting it to work in all cases.

Truth be told, I’ve used “volatile” in proprietary languages,
e.g. PLUS, because it was reliable — the compiler guy was
right down the hall, and beatings were seldom required

For C, I’ve always punted, and done volatile access in ASM.

I tested M32C/90,80,M16C/80,70 Series C Compiler V.5.41 Release 01, hosted on Windows XP, using maximum speed optimization (-O3 -Os). The C compiler performed the load in all four cases. No C++ compiler is available.

When calling assembly code from C++ I often must use extern “C” … because the assembler refuses to create/use externals like “fifoInit()” for the C++ “void fifoInit(void)”. At least the linker error is obvious.

My thinking goes like this –

Any change in chip vendor such as between Luminary Micro and ST for Cortex-M3 is far from a “recompile and you are done” effort. Thus microcontroller vendor unique code will have to be rethought anyway.

My assembly language skills have other uses. Once I had to resolve a struct that appeared to act differently under C and C++. The problem was “typedef BOOL” in C++ it turned into bool, while in C is was unsigned int. (This was 32-bit x86 code.) Nobody else realized that there was no reason for bool to be 32 bits. A quick conformation using sizeof in a C and C++ module confirmed my supposition. Changed int to char and all was well.

Please allow a somewhat OT drift

While employed at a disk drive company I worked on an embedded drive test system. I was responsible for buffer allocation. The system featured a script from which the actual tests were called. My buffer allocation ran as script pre-allocating one large chunk of RAM then splitting this RAM into various sized buffers. Script said how many buffers of each size. There was zero heap allocation/deallocation at run time.