From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9161 Path: news.gmane.org!not-for-mail From: Torvald Riegel Newsgroups: gmane.comp.gcc.devel,gmane.linux.lib.musl.general Subject: Re: SH runtime switchable atomics - proposed design Date: Thu, 21 Jan 2016 12:22:08 +0100 Message-ID: <1453375328.23593.20.camel@localhost.localdomain> References: <20160119202851.GA18720@brightrain.aerifal.cx> <1453331298.3681.58.camel@t-online.de> <20160121012229.GT238@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1453375380 31543 80.91.229.3 (21 Jan 2016 11:23:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Jan 2016 11:23:00 +0000 (UTC) Cc: Oleg Endo , gcc@gcc.gnu.org, musl@lists.openwall.com To: Rich Felker Original-X-From: gcc-return-189769-gcg-devel-2=m.gmane.org@gcc.gnu.org Thu Jan 21 12:22:48 2016 Return-path: Envelope-to: gcg-devel-2@plane.gmane.org Original-Received: from server1.sourceware.org ([209.132.180.131] helo=sourceware.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aMDKB-0004W5-Hr for gcg-devel-2@plane.gmane.org; Thu, 21 Jan 2016 12:22:47 +0100 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; q=dns; s= default; b=MLBUSYGcMcERkU4frnys0NRBGezw80ZvbYFp3eUO/dja1BWc9pcxo mgwOP+t7XnBBTSsPywEcxZ6M7lZtqP/1cQHUmuYTHNlWHra3xMhfxnmaz7F5RgfK dVqTkVDCh15Qy5qRMblJT9CP+7AyefyU8uOvjzTRXILE6Y6XQ2vlzo= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :message-id:subject:from:to:cc:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; s=default; bh=TT7aBsnH6wX6AMGOPfPtRqeOELU=; b=rLxphw/QCl1xJ3JmtYBMY6xMIQp0 VaZHFICQEAi3TWUCdVBjEzSHnIXw6snC57Y9kzFqIUpsfGIq1K3tl+E9DR7WlA+N XMrQJbVuz14frZY48Lj/Qf40f7LbUBCwHPf1tnQVY/3lixzt2KQrhjETC27cXIwN Hw/IphvmEQzZVAU= Original-Received: (qmail 81638 invoked by alias); 21 Jan 2016 11:22:16 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Original-Sender: gcc-owner@gcc.gnu.org Original-Received: (qmail 81615 invoked by uid 89); 21 Jan 2016 11:22:14 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.8 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Oleg, musl, oleg, switchable X-HELO: mx1.redhat.com Original-Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 21 Jan 2016 11:22:13 +0000 Original-Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 7D4CFC796D; Thu, 21 Jan 2016 11:22:12 +0000 (UTC) Original-Received: from [10.36.7.34] (vpn1-7-34.ams2.redhat.com [10.36.7.34]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0LBM9CM001689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA256 bits=256 verify=NO); Thu, 21 Jan 2016 06:22:10 -0500 In-Reply-To: <20160121012229.GT238@brightrain.aerifal.cx> X-IsSubscribed: yes Xref: news.gmane.org gmane.comp.gcc.devel:142275 gmane.linux.lib.musl.general:9161 Archived-At: On Wed, 2016-01-20 at 20:22 -0500, Rich Felker wrote: > On Thu, Jan 21, 2016 at 08:08:18AM +0900, Oleg Endo wrote: > > Do you have plans to add other atomic operations (like > > arithmetic)? > > No, at least not in musl. From musl's perspective cas is the main one > that's used anyway. But even in general I don't think there's a > significant advantage to doing 'direct' arithmetic ops without a cas > loop even when you can (with llsc, gusa, or imask model). With gusa > and imask the only time you benefit from not implementing them in > terms of cas is on the _highly_ unlucky/unlikely occasion where an > interrupt occurs between the old-value read before cas and the cas. > For llsc there's more potential advantage because actual smp > contention is possible, but sh4a is probably not a very interesting > target anymore. Things like atomic increments are combinable, so you can make them scale better. You can do combining too with CAS, but if you're using the CAS to implement an increment, the program would have to issue another CAS, so you're not gaining as much.