
X86-TSO: A Rigorous and Usable Programmer’s Model for x86 Multiprocessors (2010) - nkurz
http://www.cl.cam.ac.uk/~pes20/weakmemory/cacm.pdf
======
solarexplorer
Memory ordering specs are a minefields. I commend the authors for demanding
formal specifications from the manufacturers. But I don't think that the
solution is to come up with new alternative specs line x86-TSO. It is the
manufacturers that have to guarantee us programmers a well defined behavior,
that all of their current and future chips will comply to.

The fact that Intel had to relax their spec, to allow for observed behavior of
their chips is ridiculous. I guess they need those formal specifications for
their internal testing as much as we programmers do.

Parallel programming is hard enough, the manufacturers need to get their act
together if they want to continue to sell those multicores...

~~~
mafribe
One of the reasons why manufacturers don't like to give fully formal
specifications (they have them) to programmers is to avoid legal action if
they change the CPU implementation.

~~~
solarexplorer
You mean manufacturers want to avoid legal action when they break their own
specs? They already did, the paper contains an example.

The point of an architecture specification is not to dictate a specific
hardware implementation, but to establish a contract between hardware and
software. When both parts comply, then the new implementation of a chip will
run the old software without problems. A _formal_ specification is just a
better contract. Of course it limits future implementation options, but if you
want to stay backward compatible, you are limited anyway.

------
userbinator
x86 has always been almost but not quite completely backwards-compatible in
the "edge cases", ever since the 286 changed what PUSH SP put on the stack.
With regards to memory ordering, x86 is already considerably much more
restrictive than other architectures, although that might start to change in
the future...

Trying to read this paper, what's a little annoying is that the authors don't
seem to define the important acronyms and/or leave them to forward references:
"SB" I assume meant "Sandy Bridge" (i.e. that was observed beginning with that
microarchitecture) until a little later when I realised they were talking
about store buffers, "IRIW" (is it somehow related to "IWP"?) is never
defined. Also odd are the examples named "n6", "n5", and "n4b" in that order;
a subtle pun about ordering?

~~~
kropotkin
IRIW stands for "independent reads of independent writes".

IWP stands for "Intel white paper".

The submitted article (published in CACM) is a less formal and condensed form
of [https://www.cl.cam.ac.uk/~pes20/weakmemory/x86tso-
paper.pdf](https://www.cl.cam.ac.uk/~pes20/weakmemory/x86tso-paper.pdf) which
does, in fact, define all of its acronyms and include examples numbered n1
through n8.

