Collective Tuning Center to automate compiler, architecture and program design is now open for testing

If you're going to encourage people to play even _more_ games with the compiler output, you should consider a test suite that addresses this:

...snip...

Years ago I used to love watching a British TV show called "Red Dwarf" about a guy on a mining spaceship who had been in suspended animation for a million years, give or take. His only companions were a computer generated hologram, the ship computer, a mechanoid and a dude who was evolved from the cat that the main character had smuggled on board before the voyage.

The cat was self absorbed, overly concerned with food and not very bright. If he saw something he didn't know he would ask, "What is it?. It would be explained to him in some technical detail, he would listen, appear to understand, then turn to someone else in the room and ask, "What is it?" This would repeat until someone would finally say, "It's a big red ball that's going to make a big boom!" or the like.

My response to this web site it, "What is it?"

Rick

Thanks, Tim. Regardless of the OP's own interests, that paper appears to need serious reading by anyone performing embedded software work. I wasn't aware of it until now, so thanks.

Jon

Can someone explain the example in 2.1 (where a volatile is used to signal that a buffer has been cleared)?

I would have indeed expected that to work, and in fact have used such contructions when signalling from an ISR!

The authors say that the compiler is free to move the volatile access to before the for loop. It also says volatile accesses cannot be moved across sequence points. Yet surely the for loop is (at least one) "sequence point"? They imply it is not, because it "has no side effects"... but it clears the buffer! What does a side effect consist of, then?

I read that, as well. I've been more cautious than you, I suppose, because in threaded cases I've always preferred to use an O/S call to handle signaling. Written well, it's very cheap to do and since I write my own O/S I make sure of it.

But I take the point of the authors on this. The c standard does NOT seem to specify the relative ordering of memory accesses. They also brought in the idea of hardware, too, just to make that point clearer. Look that part over closely.

Just to make this clearer to you, keep in mind the case of a single CPU (let's ignore for now the dual and quad core Intel parts) based on the P2/P3/P4 designs. In these, there is a chipset also included. This chipset handles the memory interfacing to various types of DRAM, as well as accesses to memory systems that are attached to various other interfaces like the PCI bus, the AGP, and so on. The chipset obeys some rules regarding the PCI bus in terms of access order, but even then it supports read-around-writes and other optimizations which may not guarantee what you imagine. In the case of a bus specifically centered on graphics boards, like the AGP, even these weak rules are further relaxed so that there is almost no ordering imposed, at all.

In addition, there are issues regarding the various caches of a single cpu (L1 and L2), rules imposed (or not) using the MTRRs, and so on. Now layer in dual-core and quad-core cpus into this picture.

The lesson here is that it is NOT the c compiler's job to deal with all this, regarding volatiles. It's crazy-minded to imagine that a c compiler would manage all this on a target as you would hope for.

I still use volatile when order relative to non-volatiles isn't important. And in the case of threads, I have tended to use O/S functions for the purpose or simple functions as the paper suggested. I didn't know why I developed that tendency, but now I have something to hang my behavioral hat on.

Jon

Think of it as the volatile access staying in the same place, but the buffer access moving ('cause the buffer isn't volatile).

So the _loop_ has a side effect on the _buffer_, but that doesn't matter because the buffer isn't declared volatile, and is therefore free game for the optimizer.

From section 5.1.2.3 of the draft: "Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects, which are changes in the state of the execution environment. Evaluation of an expression in general includes both value computations and initiation of side effects. Value computation for an lvalue expression includes determining the identity of the designated object."

The loop modifies objects, therefore it has side effects, therefore their statement that "The for-loop does not access any volatile locations, nor does it perform any side-effecting operations" is incorrect, therefore the conclusion is bogus.

It's a bit disturbing that their Table 1 doesn't correlate the error rate with the optimization level.

Yes but... That does not explain their example! They claim it goes wrong because the *compiler* moves the loop, not because of any sneaky hardware playing tricks behind the scenes. And if it can do this, how can you possible know it is not going to do the same with your officially sanctioned OS call?

So the loop is not a "sequence point" then?

Yes, I agree with you about what they said. I'm not experienced in writing c compilers sufficient to tell you they are right or wrong. So we need to let wiser heads inform us about that. At the time I was reading it, I accepted things on their authority.

Your question may be valid, given my ignorance.

In the case of the o/s call, the very fact that the call is outside of the c code means the c compiler must handle it correctly, for one thing. As the authors point out, if compilers didn't get that much right then there would be far more serious problems. Moving calls around isn't likely.

In the case of code I write for o/s work, I'm usually intimately aware of the entire hardware environment and can take appropriate measures (modifying MTRRs to change cache rules, invalidating cache, etc.) In embedded processors, it's usually not nearly as complex as things are with the P2/P3/P4 families, though, which support multiple cpu chips on the front side bus and multiple cores in each chip. If you are confused about the idea that I might use a c compiler for the o/s, don't be. I use c where it makes sense (much of the code is operating in a situation where I'm in full control) and use assembly as needed, too. c doesn't have all the necessary semantics, though, so most everything O/S-wise I've ever written has always included some key routines written in assembly. And in a few cases long ago, entirely in assembly.

Jon

Their premise was that a buffer-clearing loop has no side effects. They could argue they are not moving the call but moving the other "side-effect-less" code around it (as Tim explained for the volatiles).

To be precise, they said that the compiler is free to move the for loop below the volatile access, which is a slightly different thing.

It depends on what "modifying and object" means. I don't have the C standard handy, but in the formal semantics of other languages I am aware of, there is a difference between assigning to a variable and modifying an object stored in a variable.

I'm afraid I don't understand this either. Unless you are talking about the possibility of a read-modify-write (like an increment) vs a write? But they both "modify" the variable.

If you only move side-effect free code around accesses to volatiles, you cannot change the relative ordering of accesses to volatiles.

Let's say you have a pointer variable that points to a heap-allocated struct. You can assign to the variable but leave the structure unchanged, or you can modify the struct but leave the pointer unchanged.

I don't know the terminology of the C standard, but in the context of some other languages assigning a new value to the variable would not be considered modifying an object. The object (struct) is unchanged, and could still potentially be accessed via other pointers.

The Standard is pretty clear; one "side effect" of an assignment operator is the storage of a value in the object designated by the left operand, which is sequenced after the value computations of the left and right operands.

There's a sequence point after the assignment expression. A sequence point requires that all value computations and side effects of the expression before the sequence point must occur before any value computation or side effect in the subsequent expression.

Under the "as if" rule, a compiler can indeed reorder the execution of expressions (or even neglect their evaluation) *if* the resulting behavior is in all regards indistinguishable from the behavior described by the abstract machine in section 5.1.2.3.

The paper's key contention that the loop in question does not "perform any side-effecting operations" is simply wrong.

Thank's Rich.

I will inform my serial ISRs that they are allowed to carry on working, for the moment.

Stuff about machine learning making your compiler spit out better code.

;-)

Bjoern

So I guess it doesn't makes sense to declare volatile a flag that a buffer has been cleared, without declaring the buffer itself volatile. I can imagine that.

Groetjes Albert

--