Intel x86 memory model question
|
Prev: CPU <> Memory chip communication interface
Next: interrupting for overflow and loop termination
From: Joe Seigh on 30 Aug 2005 08:21 The question isn't what is the x86 memory model. If you want to discuss that, you are welcome to join the fray on c.p.t. The question is why can't or why doesn't Intel want to document the x86 memory model since apparently what is in the System Programming Guide is *not* the memory model. I.e. not as far as program observable behavior is concerned though it may be if you have tracing scopes attached to the memory bus. Is this some kind of Intel State Secret? Is writing correct multi-threaded programs not in Intel's interest? -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software.
From: MitchAlsup on 30 Aug 2005 15:55 I didn't find it in the Intel book I have (Pentium Pro) But chapter 7 in Volume 2 of AMD x86-64 Architecture Programmer's Manual (System Programming) describes AMD's side of the situation, starting on page 191 of the Purple Volume. The problem is when you consider the number of memory modes {UC, CD, WC, WP, WT and WB} that no simplistic statement can fully address what the programmer can assume about memory and its ordering properties. WriteBack (cacheable) memory is, however, Processor Consistent.
From: Joe Seigh on 30 Aug 2005 17:09 MitchAlsup(a)aol.com wrote: > I didn't find it in the Intel book I have (Pentium Pro) > > But chapter 7 in Volume 2 of AMD x86-64 Architecture Programmer's > Manual (System Programming) describes AMD's side of the situation, > starting on page 191 of the Purple Volume. > > The problem is when you consider the number of memory modes {UC, CD, > WC, WP, WT and WB} that no simplistic statement can fully address what > the programmer can assume about memory and its ordering properties. > WriteBack (cacheable) memory is, however, Processor Consistent. > The argument being presented in c.p.t. is that processor consistency implies loads are in order, perhaps instigated by something Andy Glew said about this here http://groups.google.com/group/comp.arch/msg/96ec4a9fb75389a2 AFAICT, this is not true for 3 or more processors. E.g. processor 1 stores into X processor 2 see the store by 1 into X and stores into Y So the store into Y occurred after causal reasoning. processor 3 loads from Y processor 3 loads from X If loads were in order you could infer that if processor 3 sees the new value of Y then it will see the new value of X. But the rules for processor consistency *clearly* state that you will necessarily see stores by different processors in order. While there are still ordering constraints on the loads they don't have to be strictly in order as Andy incorrectly infers. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software.
From: Joe Seigh on 30 Aug 2005 17:41 Joe Seigh wrote: > > processor 1 stores into X > processor 2 see the store by 1 into X and stores into Y > > So the store into Y occurred after causal reasoning. > > processor 3 loads from Y > processor 3 loads from X > > If loads were in order you could infer that if processor 3 > sees the new value of Y then it will see the new value of X. > But the rules for processor consistency *clearly* state that > you will necessarily see stores by different processors in > order. that should be But the rules for processor consistency *clearly* state that you will not necessarily see stores by different processors in order. -- Joe Seigh When you get lemons, you make lemonade. When you get hardware, you make software.
From: already5chosen on 30 Aug 2005 18:42
Joe Seigh wrote: > The question isn't what is the x86 memory model. If you > want to discuss that, you are welcome to join the fray on > c.p.t. The question is why can't or why doesn't Intel > want to document the x86 memory model since apparently > what is in the System Programming Guide is *not* the > memory model. I.e. not as far as program observable > behavior is concerned though it may be if you have > tracing scopes attached to the memory bus. > I don't understand what's particularly wrong with paragraph 7.2.2 ftp://download.intel.com/design/Pentium4/manuals/25366816.pdf Could you be a bit more specific. > Is this some kind of Intel State Secret? Is writing > correct multi-threaded programs not in Intel's interest? > Obviously, writing correct multi-threaded SMP programs is in Intel's interest. However, according to my understanding, Intel couldn't care less about _lockless_ multi-threaded SMP programs. The reasons are clear: 1. That's such a tiny niche! 2. Average programmer can't do it correctly regardless of the quality of documentation. > -- > Joe Seigh > > When you get lemons, you make lemonade. > When you get hardware, you make software. |