From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17487 invoked by alias); 4 Nov 2016 18:44:41 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 17477 invoked by uid 89); 4 Nov 2016 18:44:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=casa, H*UA:6.0, Hx-languages-length:1551, LEON3 X-HELO: shards.monkeyblade.net Date: Fri, 04 Nov 2016 18:44:00 -0000 Message-Id: <20161104.144427.831418313476119230.davem@davemloft.net> To: andreas@gaisler.com Cc: libc-alpha@sourceware.org, adhemerval.zanella@linaro.org, carlos@redhat.com, triegel@redhat.com, software@gaisler.com Subject: Re: [RFC][PATCH 2/2] sparc32: Use cas for atomic_* operations and use general pthread_barrier_wait From: David Miller In-Reply-To: <20161104.143710.2239577261242146927.davem@davemloft.net> References: <1478012867-6031-1-git-send-email-andreas@gaisler.com> <1478012867-6031-3-git-send-email-andreas@gaisler.com> <20161104.143710.2239577261242146927.davem@davemloft.net> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00197.txt.bz2 From: David Miller Date: Fri, 04 Nov 2016 14:37:10 -0400 (EDT) > From: Andreas Larsson > Date: Tue, 1 Nov 2016 16:07:47 +0100 > >> This uses the CASA compare and swap with user space data access ASI 0xa >> that is present on many LEON3 and LEON4 systems and that is implied by >> gcc's -mcpu=leon3. >> >> The CASA instruction is used not only for atomic compare and exchange >> functions, but also atomic exchange functions and atomic write >> functions. This is to allow the OS kernel to emulate that instruction on >> systems where it is missing and to get atomicity between all atomic >> writing functions without having to resort to stop all CPU:s in an SMP >> system. > > Ok, this is fine. I'll work on the instruction emulation code for the > kernel side. Actually, this might cause some problems actually. We don't always have access to a proper _dl_hwcap value. Which means that we will emit the LEON CAS sometimes when running on a v9 chip which will not work properly. I need to think about this a bit more. Probably what we need to do is have three cases: 1) We explicitly know we are on a v9 chip via dl_hwcap, emit v9 CAS 2) We explicitly know we are on a v8 LEON chip via dl_hwcap, emit LEON CAS 3) Else, we emit a special trap instruction which the kernel fixes up I think this is necessary because we cannot attempt to execute one of the two CAS cases on the opposing CAS cpu type.