From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.user Subject: Re: Some introductory docs about C level threading Date: Tue, 1 Feb 2005 19:38:03 -0500 Message-ID: References: <6b496d191d7216e82df4e9a7afbb3168@raeburn.org> <87fz0falxl.fsf@zip.com.au> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1107314027 12645 80.91.229.2 (2 Feb 2005 03:13:47 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 2 Feb 2005 03:13:47 +0000 (UTC) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Wed Feb 02 04:13:45 2005 Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1CwAxY-0002Hk-BV for guile-user@m.gmane.org; Wed, 02 Feb 2005 04:13:40 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CwBAa-0004dk-Sq for guile-user@m.gmane.org; Tue, 01 Feb 2005 22:27:08 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1CwB7f-0003Lh-D9 for guile-user@gnu.org; Tue, 01 Feb 2005 22:24:07 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1CwB7X-0003HP-97 for guile-user@gnu.org; Tue, 01 Feb 2005 22:24:03 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1CwB7T-0003AU-PR for guile-user@gnu.org; Tue, 01 Feb 2005 22:23:55 -0500 Original-Received: from [207.172.4.62] (helo=smtp03.mrf.mail.rcn.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CwAWy-0000uV-1w for guile-user@gnu.org; Tue, 01 Feb 2005 21:46:12 -0500 Original-Received: from 216-15-127-174.c3-0.smr-ubr3.sbo-smr.ma.cable.rcn.com ([216.15.127.174] helo=raeburn.org) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.35 #7) id 1CwAWx-0006xU-00 for guile-user@gnu.org; Tue, 01 Feb 2005 21:46:11 -0500 Original-Received: from [18.101.0.226] (laptop.raeburn.org [18.101.0.226]) by raeburn.org (8.12.11/8.12.11) with ESMTP id j122kAAN000832; Tue, 1 Feb 2005 21:46:10 -0500 (EST) In-Reply-To: <87fz0falxl.fsf@zip.com.au> Original-To: guile-user@gnu.org X-Mailer: Apple Mail (2.619.2) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org X-MailScanner-To: guile-user@m.gmane.org Xref: main.gmane.org gmane.lisp.guile.user:4203 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:4203 On Feb 1, 2005, at 18:40, Kevin Ryde wrote: > Ken Raeburn writes: >> -> (....x)[0] = ((... i >> 2) << 2 + scm_tc2_int) >> -> copy i, masking off bottom two bits, into target location; then >> add >> in scm_tc2_int > > Any sensible compiler should do the one store that's given, and the Not if you have an architecture where memory-to-memory arithmetic operations are cheap and registers are few. By "copy i, masking" I didn't mean "copy to register, do the mask, then store", I meant something like "andl (r0),i,-4; addl (r0),2". In fact, for one architecture I've got in mind, another two-instruction sequence, a simple memory-to-memory copy followed by overwriting just the low two bits, would also do the trick. As it happens, that architecture isn't especially register-starved, but one could probably construct a function using a lot of temporaries and increase pressure on the register allocator such that it might still be worth avoiding the register temporary. (Sorry, I've done a little compiler hacking in my time...) > SCM type will mean it's atomic. If use of the SCM type is assumed to be atomic in terms of CPU memory access and inter-CPU memory consistency, that's fine, but it should be documented as such -- and we should acknowledge that ports to architectures where that assumption does not hold may not be possible. > You can force load/stores to be exactly as given using `volatile', but > as far as I can tell this particular example shouldn't need that. The problem is, if there are any case where it would be needed, then we need to use it everywhere there could be a potential problem. Depending on just how it works out, that could mean essentially declaring some of the scheme object types (like cons cells) as volatile, which would be poor for performance. And volatile declarations may fix the possibility of storing incomplete values, but I don't think it would deal with the cross-thread memory access ordering issue. Ken _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user