Re: Portable memory barrier?

[Robert Eachus <rieachus@comcast.net>]

One sentence summary: The CPU will play lots of tricks behind your back, but in such a way you can pretend your code works as you intended.  (Er, after you get the bugs out.)

On Monday, May 8, 2017 at 3:45:26 AM UTC-4, Dmitry A. Kazakov wrote:

> I don't believe either of the sequences can get reordered by the CPU, 
> but it is only belief and common sense.

Silly rabbit, Trix are for kids.  Oops, silly programmer, common sense has nothing to do with modern CPUs.

If I didn't make it clear, modern CPUs analyze which pending instructions can be done NOW, and they select some subset of those operations. This is called OoO (out of order) scheduling.  In addition, the CPU has a register file with lots of extra registers. It uses register renaming to insure that instructions "see" the right arguments, even if there are four or five different copies of the index in the register file.  This allows the CPU to put only one copy in the write pipe, and run the code faster than a naive counting of writes to memory suggests.  Finally, superscalar CPUs convert the instructions into micro-ops (name depends on CPU vendor) and then several of these micro-ops belonging to multiple instructions get executed all at once.

The CPU tries hard to eliminate reads and writes to main memory which are slow.  By putting the memory controller on the CPU, and having it look into the cache no matter the source of the request, even volatile memory can be virtualized.  (There are a few pages in memory which can't be virtualized, because they contain things like the real-time clock.  But that is a detail known to the CPU.)

All of this is done with state not associated with any real clock, but with the instructions as they execute.  If you think of a program counter as a pointer to the next instruction to be executed, and defining a state; modern CPUs have multiple states in play at the same time--and out of order.

Since in all this the CPU arranges things so that all of the outputs occur in the expected order. If you halt the CPU, then flush the cache, THEN there will be one point in the programmer's view of the code that corresponds to the current state--in other words, debuggers work.  (Assuming you look at the code as generated, or turn off optimization in the compiler.)

As far as this issue is concerned, the CPU implements the ISA, so you get the effects you expect from a program.  All of this is on an "as if" basis, and in fact the CPU is seldom in a reproducible state.

Is any of this important to a high-level language programmer?  Not really, unless they are working in hard real time. (Which I did.)  If you program in assembler, or more likely work on a compiler back-end, knowing which instructions fit together is important.  Even more important is coding so that an instruction that references a new cache line in memory is followed by as many instructions as possible that don't use that value.  Some times you run into cases where you want to take advantage of write combining or some other trick involving the write pipe--but today, smart compiler optimization is about accesses to main memory and not much else.