 | This article is rated C-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
| |||||||||||
untitled
editThis page contains some disjoint items relating to both Memory barrier and Memory model and perhaps other topics. IMHO it should be reassembled under those topics. Wheezil (talk) 17:17, 6 December 2011 (UTC)
Table of Architectures
editThe table "Memory ordering in some architectures" is misleading or incorrect.
Does 'Y' mean that the memory ordering is allowed, or disallowed? I would assume Allowed, except the Intel whitepaper referenced in the footnotes contradicts that In fact, based on the Intel White paper the IA64 column should read:
Loads after Loads: Not allowed
Loads after Stores: Allowed if referencing different locations,
otherwise not allowed
Stores after Stores: Not allowed
Atomic reordering with loads: Not allowed
Atomic reordering with Stores: Not allowed
Dependent Loads Reordered: Not Allowed
No interpretation of 'Y' matches this information.
74.114.36.65 (talk) 18:40, 6 July 2012 (UTC)
Pretty sure Y means allowed, and I think the table is correct. It comes from the paper "Memory Ordering in Modern Microprocessors" by Paul McKenney (2007 version). The Intel whitepaper you mention covers the Intel 64 architecture, which is Intel's implementation of x86-64. Intel 64 would correspond most closely to the AMD64 entry the table. IA64 refers to the Intel Itanium Architecture. The correct reference for the Itanium architecture's memory model is the Intel Itanium Architecture Software Developer's Manual, whose description in Volume 2 section 2.2.1.2 matches the data in the IA64 column. Dreamhammer (talk) 16:59, 2 April 2014 (UTC)
External links modified (January 2018)
editHello fellow Wikipedians,
I have just modified 2 external links on Memory ordering. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:
- Added archive https://web.archive.org/web/20110724181810/http://lxr.linux.no/linux+v2.6.31/include/linux/compiler-gcc.h to http://lxr.linux.no/linux+v2.6.31/include/linux/compiler-gcc.h
- Added archive https://web.archive.org/web/20110724181824/http://lxr.linux.no/linux+v2.6.31/include/linux/compiler-intel.h to http://lxr.linux.no/linux+v2.6.31/include/linux/compiler-intel.h
When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.
This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 5 June 2024).
- If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
- If you found an error with any archives or the URLs themselves, you can fix them with this tool.
Cheers.—InternetArchiveBot (Report bug) 15:46, 25 January 2018 (UTC)
"Incoherent instruction cache pipeline" on x86
editAFAIK x86 has coherent instruction cache and instruction pipeline. Maybe this changed in amd64 to be incoherent, but even there I think it is coherent. So I think there is a bug in the table, which says that x86 has "Incoherent instruction cache pipeline". 81.6.34.172 (talk) 00:44, 18 May 2020 (UTC)
Essay added
editThis is difficult subject area and the previous content about compiler ordered was barely informative for any audience: the novices would not have gained much, and the experienced already knew far more.
I just replaced this with an explanatory essay which is at least somewhat accessible to a relatively novice programmer.
My track record with this kind of addition to Wikipedia is variable. Sometimes the next editor comes along and blows the whole thing away with a quick revision (fair enough).
Other times, accessibility is valued over formality, and my contribution is retained and reworked.
My policy is to take zero future ownership of my past contributions. Whatever may be, may be.
If it does get summarily blown away, an interested party can find my contribution in the edit history. It would at least function as a useful outline for how much this article fails to explain in its present state. — MaxEnt 18:43, 27 September 2020 (UTC)