Intel x86 memory model question
|
From: Joe Seigh on 6 Sep 2005 08:02 Alexander Terekhov wrote: > Andy Glew wrote: > > >>You are confusing implementation with semantics. > > > Fix the specs, then. I think you can assume that the serializing stuff does the right thing. If not and you have strong reason to believe otherwise, then you should short Intel stock as you'd stand a pretty good chance of making a fortune. Basically, no OS would work correctly on an Intel based multi-processor server and Intel would be out of that business. Also Intel would be screwed in the multi-core workstation and desktop market as it would be too late to fix the current processors going into production. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software.
From: David Hopwood on 6 Sep 2005 08:54 Joe Seigh wrote: > David Hopwood wrote: >> Joe Seigh wrote: >>> David Hopwood wrote: >>> >>>> Of course not. Read what they actually wrote. >>> >>> I did. It sounded to me like they said if you want to write >>> portable code, don't assume processor ordering but use the >>> locking and serializing instructions instead on the current >>> processors. >> >> But OSes, thread libraries and language implementations *aren't* portable >> code. > > I do not think that word means what you think it means. > > Note that I am an ex-kernel developer and have created enough > sychronization api's that run on totally different platforms. You are totally missing the point. OSes, thread libraries and language implementations have some code that needs to be adapted to each hardware architecture. If the memory model were to change in future processors that are otherwise x86-like, this code would have to change. It's not a big deal, because this platform-specific code is maintained by people who know how to change it, and because there are few enough OSes, thread libraries, and language implementations for the total effort involved not to be very great. It would, however, be a big deal if existing x86 *applications* stopped working on an otherwise x86-compatible processor. -- David Hopwood <david.nospam.hopwood(a)blueyonder.co.uk>
From: Joe Seigh on 6 Sep 2005 09:49 David Hopwood wrote: > Joe Seigh wrote: > >> David Hopwood wrote: >>> >>> But OSes, thread libraries and language implementations *aren't* >>> portable >>> code. >> >> >> I do not think that word means what you think it means. >> >> Note that I am an ex-kernel developer and have created enough >> sychronization api's that run on totally different platforms. > > > You are totally missing the point. OSes, thread libraries and language > implementations have some code that needs to be adapted to each hardware > architecture. If the memory model were to change in future processors > that are otherwise x86-like, this code would have to change. It's not a > big deal, because this platform-specific code is maintained by people who > know how to change it, and because there are few enough OSes, thread > libraries, and language implementations for the total effort involved > not to be very great. It would, however, be a big deal if existing x86 > *applications* stopped working on an otherwise x86-compatible processor. > I am talking about that. You insist on maintaining that I advocate applications hardcode platform specific assembly code into their source. I never have advocated that. But when you design these api's you have to have a pretty good idea what kinds of things an be ported and what assumptions you are making about the memory model. Since I've actually done this kind of stuff I probably have a much better idea than you have what the actual issues are. And yes, there isn't any assumption about the memory model that can't be broken by a hardware designer. The only thing that keeps hardware companies from breaking widely used api's like Posix pthreads is they might go out of business if they did. Hence, shorting Intel stock might be a good idea if you believe they did do that. But saying that we should only use widespread api's and not ever create any new ones is ridiculous. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software.
From: Eric P. on 6 Sep 2005 10:26 Alexander Terekhov wrote: > > My reading of the specs is that MFENCE is guaranteed to provide > store-load barrier. > > P1: X = 1; R1 = Y; > P2: Y = 1; R2 = X; > > (R1, R2) = (0, 0) is allowed under pure PC, but > > P1: X = 1; MFENCE; R1 = Y; > P2: Y = 1; MFENCE; R2 = X; > > (R1, R2) = (0, 0) is NOT allowed. Are you sure you are not being inconsistent in example 2 here? (wrt what you answered yesterday about S/LFENCE). If MFENCE is just an SFENCE+LFENCE, and neither of those guarantee delivery or receipt of invalidates, then P1 can have a stale Y and P2 a stale X. The MFENCE does nothing but prevent bypassing. Eric
From: Eric P. on 6 Sep 2005 10:58
"Eric P." wrote: > > Alexander Terekhov wrote: > > > > My reading of the specs is that MFENCE is guaranteed to provide > > store-load barrier. > > > > P1: X = 1; R1 = Y; > > P2: Y = 1; R2 = X; > > > > (R1, R2) = (0, 0) is allowed under pure PC, but > > > > P1: X = 1; MFENCE; R1 = Y; > > P2: Y = 1; MFENCE; R2 = X; > > > > (R1, R2) = (0, 0) is NOT allowed. > > Are you sure you are not being inconsistent in example 2 here? > (wrt what you answered yesterday about S/LFENCE). > > If MFENCE is just an SFENCE+LFENCE, and neither of those guarantee > delivery or receipt of invalidates, then P1 can have a stale Y > and P2 a stale X. The MFENCE does nothing but prevent bypassing. > > Eric Forget it, I see. With two processors Y can be stale on P1, or X stale on P2, but not both. Eric |