Linus Torvalds (torvalds@osdl.org) on 10/27/06 wrote:
---------------------------
>Rob Thorpe (rthorpe@realworldtech.com) on 10/27/06 wrote:
>>
>>You can't not have special cases. Everything a
>>microprocessor does is a special case tailored to some
>>set of particular applications.
>
>My point, which you seem to totally miss, over and over
>again, is that certain design approaches makes this worse.
>
>For example, there is the approach that x86 chose (never
>mind the reasons):
>
>- memory ordering is totally an internal issue, and
>memory barriers aren't needed, because we will just
>make the uarch do the rigt thing
>
>is fundamentally more robust than the approach
>most RISC vendors took.
>
>In other words, while the two are "equally good" in theory
>(and, in fact, release consistency might be better in
>theory), in practice it is better to just
>not even aim for the theory.
>
>Why is that so hard for people to understand? You should
>avoid special cases in the first place, not optimize for
>them.
>
>So the fact is, you very much can "not have special
>cases" in most settings. Yes, you'll inevitably need them
>for something, but if you can avoid them, you're a
>lot better off.
>
>The x86 memory ordering is one such thing. It didn't have
>memory barriers, and instead of adding them, they just
>accepted the fact that they aren't needed, if you just
>see the instruction stream as largely linear, and hide the
>fact that the actual execution may not be from all other
>levels..
>
>See?
>
>The extreme way of not doing this right is to
>expose all the quirks very publicly, and make every single
>special case be an architectural feature, visible to all.
>So you'd have register renaming done in an architecturally
>visible manner, you'd have memory ordering done visibly,
>you'd have IEEE special cases done by software.
>
>That's "obviously better", because it allows the hardware
>engineers to punt the hard stuff, right?
>
>WRONG.
>
>And that's what I'm saying. Certain mental models
>are just wrong. The "let special cases be handled by others"
>is such a mental model. It may work, but it results
>in crap in the end.
>
>Linus

x86 ordering rules are by themselves a compromise between robustness (stores observed in program order by all parties) and efficiency (independent loads could be reordered). Why do you feel that this specific compromise is the most acceptable?
It seems x86 lack of ordering on loads causes no major headaches in practice solely due to the fact that typical IPC code contains atomic primitives and in case of x86 all SMP-safe atomic primitives contain memory barrier.

Rigorously applying you philosophy, “the uarch has to do the right thing” in case of the loads as well as in case of the stores.