From: Joe Seigh on
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
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
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
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

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.