From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Hopwood Subject: Re: x86-64 tools fix question Date: Wed, 02 Mar 2005 06:40:59 +0000 Message-ID: <42255FFB.2030900@blueyonder.co.uk> References: <1109707006.13010.15.camel@thinkpad> Reply-To: david.nospam.hopwood@blueyonder.co.uk Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <1109707006.13010.15.camel@thinkpad> Sender: xen-devel-admin@lists.sourceforge.net Errors-To: xen-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , List-Archive: To: xen-devel@lists.sourceforge.net List-Id: xen-devel@lists.xenproject.org Jerone Young wrote: > In the tools there is a declaration: > > #if defined(__i386__) > #define rmb() __asm__ __volatile__ ( "lock; addl $0,0(%%esp)" : : : > "memory" ) > #define wmb() __asm__ __volatile__ ( "" : : : "memory" ) > #else > #error "Define barriers" > #endif > > located in: > xcs/xcs.h > tools/python/xen/lowlevel/xu/xu.c > > I'm assuming this has a convenient side-effect that it prevents read > reordering. Otherwise I can't figure out why this is being done at all. > Now I'm guessing that that using rsp instead of esp since we are in > 64bit mode will give the same effect needed. > > #elif defined(__x86_64__) > #define rmb() __asm__ __volatile__ ( "lock; addl $0,0(%%rsp)" : : : > "memory" ) > #define wmb() __asm__ __volatile__ ( "" : : : "memory" ) > > I would like to discuss is this correct, dead wrong, or even needed at > all? See volume 1, section 3.9.2 of the AMD64 architecture manual (http://www.amd.com/us-en/Processors/DevelopWithAMD/0,,30_2252_875_7044,00.html), quoted below for convenience. This should be guaranteed to work: #define rmb() __asm__ __volatile__ ( "mfence" : : : "memory" ) #define wmb() __asm__ __volatile__ ( "mfence" : : : "memory" ) but may be overkill. Are these macros used in any performance-critical situations? If not then the overkill wouldn't matter. # 3.9.2 Forcing Memory Order # # Special instructions are provided for application software to force # memory ordering in situations where such ordering is important. These # instructions are: # * Load Fence -- The LFENCE instruction forces ordering of # memory loads (reads). All memory loads preceding the # LFENCE (in program order) are completed prior to # completing memory loads following the LFENCE. Memory # loads cannot be reordered around an LFENCE instruction, # but other non-serializing instructions (such as memory # writes) can be reordered around the LFENCE. # * Store Fence -- The SFENCE instruction forces ordering of # memory stores (writes). All memory stores preceding the # SFENCE (in program order) are completed prior to # completing memory stores following the SFENCE. Memory # stores cannot be reordered around an SFENCE instruction, # but other non-serializing instructions (such as memory # loads) can be reordered around the SFENCE. # * Memory Fence -- The MFENCE instruction forces ordering of # all memory accesses (reads and writes). All memory accesses # preceding the MFENCE (in program order) are completed # prior to completing any memory access following the # MFENCE. Memory accesses cannot be reordered around an # MFENCE instruction, but other non-serializing instructions # that do not access memory can be reordered around the # MFENCE. -- David Hopwood ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click