From: "Dr. David Alan Gilbert" <linux@treblig.org>
To: Jesse Barnes <jesse.barnes@intel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Intel Memory Ordering White Paper
Date: Wed, 12 Sep 2007 19:26:23 +0100 [thread overview]
Message-ID: <20070912182622.GA16520@gallifrey> (raw)
In-Reply-To: <200709071526.51169.jesse.barnes@intel.com>
* Jesse Barnes (jesse.barnes@intel.com) wrote:
> FYI, we just released a new white paper describing memory ordering for
> Intel processors:
> http://developer.intel.com/products/processor/manuals/index.htm
>
> Should help answer some questions about some of the ordering primitives
> we use on i386 and x86_64.
Hi Jesse,
Thanks for letting everyone know about that paper, however - it
has confused me somewhat; there seem to be differences in that
description and that described in the 'Intel 64 and IA-32 Architectures
Software Developer's Manual' and I'd like to understand whether
this paper is designed just to explain points or is actually
intended to change what can be expected of the processor.
That ordering doc states:
'Loads are not reordered with other loads'
Vol3a section 7.2.1 of the architecture manual states:
'Reads can be carried out speculatively and in any order.'
Is this a:
1) Change in the definition of the architecture that existing
processors actually follow anyway.
2) A difference between what the processor does and what is visible
to the software (the intro to this paper does seem to emphasize
software visibility more than the architecture manual).
3) Some other difference I haven't spotted.
The other thing that made me think about it was that the Itanium
Architecture Software Dev Manul vol2 2.1.2 states that the Itanium
uses ld.acq/st.rel (acquire/release) references to
'operate according to the IA-32 ordering model.' which I think means
that all those loads are in order relative to all the other acquire
loads?
Dave
--
-----Open up your eyes, open up your mind, open up your code -------
/ Dr. David Alan Gilbert | Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
\ _________________________|_____ http://www.treblig.org |_______/
next prev parent reply other threads:[~2007-09-12 18:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-07 22:26 Intel Memory Ordering White Paper Jesse Barnes
2007-09-08 8:54 ` Nick Piggin
2007-09-07 23:20 ` Linus Torvalds
2007-09-08 17:34 ` Nick Piggin
2007-09-08 17:48 ` Nick Piggin
2007-09-07 18:13 ` Nick Piggin
2007-09-08 8:53 ` Andi Kleen
2007-09-07 19:57 ` Nick Piggin
2007-09-08 10:19 ` Andi Kleen
2007-09-07 20:32 ` Nick Piggin
2007-09-08 20:37 ` H. Peter Anvin
2007-09-08 11:34 ` dean gaudet
2007-09-08 12:08 ` Petr Vandrovec
2007-09-08 12:27 ` dean gaudet
2007-09-08 10:30 ` Alan Cox
2007-09-07 20:46 ` Nick Piggin
2007-09-08 10:29 ` Alan Cox
2007-09-07 20:49 ` Nick Piggin
2007-09-08 14:11 ` Alan Cox
2007-09-12 18:26 ` Dr. David Alan Gilbert [this message]
2007-09-19 16:26 ` Jesse Barnes
2007-09-19 17:29 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070912182622.GA16520@gallifrey \
--to=linux@treblig.org \
--cc=jesse.barnes@intel.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox