From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,RDNS_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 3678 invoked from network); 13 Mar 2020 02:13:33 -0000 Received-SPF: pass (mother.openwall.net: domain of lists.openwall.com designates 195.42.179.200 as permitted sender) receiver=inbox.vuxu.org; client-ip=195.42.179.200 envelope-from= Received: from unknown (HELO mother.openwall.net) (195.42.179.200) by inbox.vuxu.org with ESMTP; 13 Mar 2020 02:13:33 -0000 Received: (qmail 26533 invoked by uid 550); 13 Mar 2020 02:13:31 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 26515 invoked from network); 13 Mar 2020 02:13:31 -0000 Date: Thu, 12 Mar 2020 22:13:18 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200313021318.GL11469@brightrain.aerifal.cx> References: <7D9266CBFB4E9A4B9C7B1D0341567D8601727F45@DGGEMI529-MBX.china.huawei.com> <20200312135715.GK11469@brightrain.aerifal.cx> <7D9266CBFB4E9A4B9C7B1D0341567D8601728046@DGGEMI529-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7D9266CBFB4E9A4B9C7B1D0341567D8601728046@DGGEMI529-MBX.china.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] =?utf-8?B?562U5aSN?= =?utf-8?Q?=3A?= [musl] musl support riscv32 On Fri, Mar 13, 2020 at 02:05:09AM +0000, chengzhiwei (C) wrote: > Thanks, Hopefully I am! > > Another thing is about atomic operation(if 32-bit based on what's > upstram in musl for riscv64), musl's atomic operation for riscv64 is > a handwritten assembly version, but some RISCV-V MCU omit such > instructions LR/SC specified in the A standard extension. Someone do > related work to support processors without atomic instructions? Or > considering the possibility of implementing the functionality in C > code. If the hardware lacks them the kernel needs to trap and emulate, or provide some other mechanism (like kuser_helper on old ARM). There's no way to have a working implementation without compare-and-swap. I've said many times that it's ridiculous that RISC-V made them optional. For a single-core CPU LR/SC are trivial to implement. LR just sets a flag and all interrupts clear the flag. SC stores only if the flag is set. Rich