From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9600 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl without atomic instructions? Date: Sat, 12 Mar 2016 19:21:40 -0500 Message-ID: <20160313002140.GG9349@brightrain.aerifal.cx> References: 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 1457828516 17997 80.91.229.3 (13 Mar 2016 00:21:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 13 Mar 2016 00:21:56 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9613-gllmg-musl=m.gmane.org@lists.openwall.com Sun Mar 13 01:21:56 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 1aetnA-00035p-9Y for gllmg-musl@m.gmane.org; Sun, 13 Mar 2016 01:21:56 +0100 Original-Received: (qmail 27659 invoked by uid 550); 13 Mar 2016 00:21:53 -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 26614 invoked from network); 13 Mar 2016 00:21:52 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9600 Archived-At: On Sun, Mar 13, 2016 at 08:47:36AM +0900, Masanori Ogino wrote: > Hello, > > While I work on my GSoC proposal, I doubt whether musl can be built > without hardware atomic operation supports. > > Could we build musl without such instructions? > If we could, what will happen with the features of musl? Atomic compare and swap (usually provided by either a direct cas instruction or ll/sc pair type) is a hard requirement for musl. The normal profiles of riscv have at least ll/sc style and possibly cas too. Minimal profiles for microcontroller use lack it (this was a mistake in the riscv ISA specification, IMO), so if supporting these ISA levels is interesting, there are at least three options: 1. Have the kernel trap the unimplemented instructions and emulate them. 2. Have userspace issue a system call to have the kernel mediate atomic accesses. 3. Integrate atomic sequence restart with the scheduler: at scheduling time, the kernel determines if the task being resumed was interrupted in the middle of a sequence of instructions that's supposed to be atomic, and if so, resets the program counter to the beginning of the sequence. (This is how pre-v6 ARM and most SH models work.) Option 3 offers by far the best performance but inherently only works on uniprocessor. Options 1 and 2 could theoretically support SMP as long as the kernel has some other way of ensuring mutual exclusion and memory synchronization between the processors. Of course the best of all worlds is to have the kernel provide a vdso function for atomic cas which it can then provide an optimal implementation of for the particular processor being used. Then baseline-ISA-level riscv binaries would use the vdso, and ones targeting an ISA level that's known to have native atomic instructions would use the inline instructions. Rich