From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9085 Path: news.gmane.org!not-for-mail From: Markus Wichmann Newsgroups: gmane.linux.lib.musl.general Subject: Re: atomic.h cleanup Date: Sun, 10 Jan 2016 18:35:09 +0100 Message-ID: <20160110173509.GG2016@debian> References: <20160110122139.GF2016@debian> <20160110165718.GR238@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1452447325 9844 80.91.229.3 (10 Jan 2016 17:35:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Jan 2016 17:35:25 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9098-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jan 10 18:35:24 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aIJtk-0007lF-Bw for gllmg-musl@m.gmane.org; Sun, 10 Jan 2016 18:35:24 +0100 Original-Received: (qmail 14321 invoked by uid 550); 10 Jan 2016 17:35:22 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 14303 invoked from network); 10 Jan 2016 17:35:22 -0000 Content-Disposition: inline In-Reply-To: <20160110165718.GR238@brightrain.aerifal.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Provags-ID: V03:K0:8TkjlM+6scZVKAWTviZheAhi2MekcMbuktA1w1UJipguq+4qhKN Y0tuWCfRP4RZwFLeK1dCI2Rw302npbOO644NWHlMjJ2JhpdvR+4mFtRCxLcP3p1YQwy8orj B/Xp3sgulbaPj7Vm8kWM0/ScU8euFC+jilEzfNHwi7SpwpyC+woik/p8tHpAlGRTXa509Gb 0PhSdLE1/57zgTFZp1eLQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:OhYAvS6eYSE=:eDkMu4VLswSUuMRXCSbYOK O5pkijkp1nJB4OQ+a2btagW5J6q+jtmhQcpChH16sVldy3yMqEVpO5JxLfmfiXyK0SvZJ3G8e pyQSXc26VGeMu7/KfBhDvWWn2hkPctK64jAfHfDBX0Q3S2nsGcYy7cwjygMT+h2rzC4RSEcqD Pxcu1sDTXNM24Ly2Gf8uBJGcwtUN7qQGgoyx+AQRJBGtXizQUk5kgw87eSgBatWhNWpcnA6O2 2/914OvKDc6f2B1OJsE0YzWfqSSdt4CZKBnmh6swDIeSe7n79HJINRR+1+5drX/SMUINZ9CaW AMVKQvDpo2A790uqmqj8fEVzO1WEwnsDn60J5I13JrYcrXEtfod7W13l9QY6tuHs4tcMAsSmb sSEG13tNbG3yDCWHj3+h6iKPGlPLOAw2lQ5TCC+wquHt0zlMtI7J/IHGxzOBvxsYgXGs3U2zh 0QSAp1lUTizyrJ2rj/3KMdx99jGUYVcG+Hn0sgbph2fR3n+s9anHD0HVHKHhVQKk4GpMhLPuu EvHozPGutNRfGlupG5H10Z5MpTHDeuZZBRCm+M5V7U1o0P4EK4y1rSUMJtabljlWvJzRCHXh/ OhUyWAnzmpucXaSexGWHxl16FJ+5jJ+VVBsfWq0w2LgEVOXkn3FFequhRn+RRqRA5hGTCLlME IEH/NxWVSBYMzT4r3Q20hCqCWzTdfJeoAvQv/KNvrr/gKqovBB4e2RV3JtpPd6j9D6tCGmwjO 46RpKtwQBFyXkVsEMN85m1Fsi5Sm0X6P838A1NYC8ZNv4+g4W1BFT4FNdGM= Xref: news.gmane.org gmane.linux.lib.musl.general:9085 Archived-At: On Sun, Jan 10, 2016 at 11:57:18AM -0500, Rich Felker wrote: > On Sun, Jan 10, 2016 at 01:21:39PM +0100, Markus Wichmann wrote: >> [...] >> What do you say to this design? > > Have you read this thread? :) > > http://www.openwall.com/lists/musl/2015/05/20/1 > > I thought at one point it was linked from the wiki but maybe it got > lost. > Well, at least it's not on the Roadmap page. There should probably be a wiki page for such open questions. Then people like me wouldn't have to ask (or do extended searches in the mailing list archives, which at the moment is only possible through your favorite search engine, BTW, which is why I've not been doing that so often). > Basically I have this done already outside of musl as an experiment, > but there are minor details that were holding it up. One annoyance is > that, on some archs, success/failure of "sc" comes via a condition > flag which the C caller can't easily branch on, so there's an extra > conversion to a boolean result inside the asm and extra conversion > back to a test/branch outside the asm. In practice we probably don't > care. > Yes, and my original message showed how to deal with that: | static inline int a_sc(volatile int* p, int x) | { | __asm__ goto ("stwcx. %0, 0, %1\n\tbne- %l2" : : "r"(x), "r"(p) : "cc", "memory" : fail); | return 1; | fail: | return 0; | } I tested the assembler output from both gcc and clang and it looks alright to me (testcase attached). As I said, we typically want to branch if SC fails, so that's how these snippets should be written (not "branch if it succeeds", because AFAICS the compiler can't rewrite the ASM snippets). > One other issue is that risc-v seems to guarantee, at least on some > implementations, stronger forward-progress guarantees than a normal > ll/sc as long as the ll/sc are in order, within a few instruction > slots of each other, with no branches between. Such conditions cannot > be met without putting them in the same asm block, so we might need to > do a custom version for risc-v if we want to take advantage of the > stronger properties. > Oh goodie, another term to research... As far as I can see, RISC-V is another architecture. Since the scheme I'm proposing is strictly opt-in, we can cross that bridge once we come to it. For instance, this scheme is insufficient to support SuperH and its three different versions of a_cas(). So I'd just leave that be for the moment. Ciao, Markus