From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25910 invoked by alias); 13 Jul 2008 22:08:21 -0000 Received: (qmail 25902 invoked by uid 22791); 13 Jul 2008 22:08:20 -0000 X-Spam-Check-By: sourceware.org Received: from hiauly1.hia.nrc.ca (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 13 Jul 2008 22:08:03 +0000 Received: by hiauly1.hia.nrc.ca (Postfix, from userid 1000) id 0F6D64E2A; Sun, 13 Jul 2008 18:08:00 -0400 (EDT) Subject: Re: [PATCH, HPPA] Atomic builtins using kernel helpers for Linux To: deller@gmx.de (Helge Deller) Date: Mon, 14 Jul 2008 01:46:00 -0000 From: "John David Anglin" Cc: gcc-patches@gcc.gnu.org, carlos@systemhalted.org In-Reply-To: <487A6448.5060402@gmx.de> from "Helge Deller" at Jul 13, 2008 10:23:36 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20080713220801.0F6D64E2A@hiauly1.hia.nrc.ca> Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2008-07/txt/msg00938.txt.bz2 > First of all I should mention, that my initial goal of this patch was to > a) try to only change necessary parts for HPPA, while keeping 95% of the > code identical to the ARM implementation (just in case it could share > code with it). I assume with your proposals below I should drop this > goal and do a HPPA-only implementation? Yes. All kinds of code in the PA implementation has been copied and customized from other targets. > b) only support 1,2 and 4byte atomic functions, same as original code > for ARM. That would be fine as the kernel doesn't support anything more. > This is due reason a) (see above). > I could do "#define KERNEL_CMPXCHG" and then a function > __kernel_cmpxchg() using this macro? I think from a performance standpoint we want __kernel_cmpxchg() to be inlined. Possibly, it could just be a defined as static inline. I don't think the macro is necessary. This may help with side effects I was wondering if the memory used by the asm should be made explicit. > Hmm. Is it needed that often? Probably, they aren't used that often. > I think atomic ops should normally operate on native types (int and long > long) only. At a minimum, I believe that the kernel support should operate on 32 and 64-bit objects in the 32 and 64-bit runtimes, respectively. This allows the exchange of pointers in each runtime. At the moment, the 64-bit support works on 32 bits. I don't think it is reasonable to handle 64-bit objects in the 32-bit runtime. > Kyle mentioned yesterday on IRC, that it probably would be better to > implement those additional functions (if they really need to be > implemented!) with VDSO, and avoid adding more functions to the LWS. The reason for using the gateway page is that processes are never scheduled off the gateway page or sent signals while on the gateway page. At the moment, it is unclear what additional overhead would be needed to do this with VDSO. It might be better to stay with shift and mask. > /* Kernel helper for memory barrier. */ > #define __kernel_dmb() asm volatile ( "" : : : "memory" ); Another thought about this. It is my understanding that the above is a full barrier. __sync_lock_release only requires a release barrier. __sync_lock_test_and_set needs an acquire barrier. It's not clear how to achieve this. > > I don't like very much the fact that the implementations loop forever > > when EFAULT or ENOSYS is returned by the kernel. > > Yes. > Any idea how to implement a fault generation or program abort in libgcc.a? There is an asm in the glibc dynamic loader to generate an insn fault. Possibly, that's the best solution as it gives the program a chance to recover. Dave -- J. David Anglin dave.anglin@nrc-cnrc.gc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6602)