From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31081 invoked by alias); 7 Jan 2003 12:08:55 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 31071 invoked from network); 7 Jan 2003 12:08:54 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by 209.249.29.67 with SMTP; 7 Jan 2003 12:08:54 -0000 Received: by nile.gnat.com (Postfix, from userid 338) id 86DA1F28F7; Tue, 7 Jan 2003 07:08:42 -0500 (EST) To: dewar@gnat.com, ja_walker@earthlink.net, lord@emf.net, mszick@goquest.com Subject: Re: An unusual Performance approach using Synthetic registers Cc: gcc@gcc.gnu.org Message-Id: <20030107120842.86DA1F28F7@nile.gnat.com> Date: Tue, 07 Jan 2003 12:32:00 -0000 From: dewar@gnat.com (Robert Dewar) X-SW-Source: 2003-01/txt/msg00345.txt.bz2 > First, XCHG is what I think of as an Operating System instruction. It is > quite valuable because the exchange can be limited to a single process on a > single processor in a multiprocessor system, in conjunction with the locking > process. It is one of the very reliable ways to implement semaphores. Please look through the instruction set more carefully, this is NOT the way you would implement any sychronization instructions on the x86. Also, be very careful about timing of instructions when you start to look at the complex instructions of the x86. No one should even think of generating code for the x86 without reading the Intel guide for compiler writers. Basically the rule on most variants of the x86 is that you should treat it as a conventional load/store RISC machine when it comes to generating code.