X86-TSO: A Rigorous and Usable Programmer’s Model for x86 Multiprocessors (2010) | Hacker News Reader

X86-TSO: A Rigorous and Usable Programmer’s Model for x86 Multiprocessors (2010)

cl.cam.ac.uk

46 pointsnkurz5 comments

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...

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.

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.

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?

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 which does, in fact, define all of its acronyms and include examples numbered n1 through n8.

Reply on news.ycombinator.com