From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL,URIBL_DBL_BLOCKED_OPENDNS,URIBL_ZEN_BLOCKED_OPENDNS autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 3845B28D3E for ; Tue, 21 Oct 2025 05:05:19 +0200 (CEST) Received: (qmail 1160 invoked by uid 550); 21 Oct 2025 03:05:14 -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 x-ms-reactions: disallow Received: (qmail 1117 invoked from network); 21 Oct 2025 03:05:14 -0000 Message-ID: <20adf11b-d19e-413a-ab7e-033b0f5f500e@isrc.iscas.ac.cn> Date: Tue, 21 Oct 2025 11:05:00 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Pincheng Wang To: musl@lists.openwall.com, nsz@port70.net References: <20250918164720.337994-1-pincheng.plct@isrc.iscas.ac.cn> <20250918164720.337994-2-pincheng.plct@isrc.iscas.ac.cn> <20251021003018.GC3520958@port70.net> In-Reply-To: <20251021003018.GC3520958@port70.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-CM-TRANSID:rQCowAA3fXdc+PZoce6TEg--.30159S2 X-Coremail-Antispam: 1UD129KBjvJXoWxZFy5ArW5KrW8KFyUtFyUGFg_yoW5ury3pF s3Crn0kF1kX34xW39aqr4UWF1rJFn5Gr4fZry3K34rZFyDWr1xCF1vkan09FnrCr4rAryj va17Wryruw45Aa7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyjb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVWUJVW8JwA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_Jr0_Gr1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG64xvF2IE w4CE5I8CrVC2j2WlYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMc vjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCF04k20xvY0x0EwIxGrwCFx2IqxVCF s4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r1j6r18MI8I3I0E7480Y4vE14v26r106r 1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxVWU JVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r 1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUv cSsGvfC2KfnxnUUI43ZEXa7IU5PpnJUUUUU== X-Originating-IP: [223.104.134.5] X-CM-SenderInfo: pslquxhhqjh1xofwqxxvufhxpvfd2hldfou0/ Subject: Re: [musl] [PATCH 1/1] riscv: add Zacas extension support for atomic CAS On 2025/10/21 08:30, Szabolcs Nagy wrote: > * Pincheng Wang [2025-09-19 00:47:20 +0800]: >> Add compile-time detection for RISC-V Zacas extension and use >> amocas.w.aqrl/amocas.d.aqrl instructions when available. >> >> When __riscv_zacas is defined, a_cas() and a_cas_p() use single amocas >> instructions instead of lr/sc loops. Falls back to existing lr/sc >> implementation when Zacas is not available. > > is this a supported extension? are there users? > (implemented on existing cpus with released toolchain versions) The Zacas extension was ratified in November 2023. CPUs such as the XuanTie C930 already support this extension [1]. For toolchain support, GCC added Zacas extension support in commit 11c2453 ("RISC-V: Add basic support for the Zacas extension") on Jul 30, 2024. Moreover, the RVA23 profile document [2] listed Zacas as a development option and states that it "is intented to become mandatory in the future RVA profile", suggesting broader adoption, particularly in high-preformance computing domains such as PCs and servers, in the near future. [1] https://www.xrvm.com/product/xuantie/C930 [2] https://docs.riscv.org/reference/profiles/rva23/_attachments/rva23-profile.pdf > what cflags enable the extension? (how to test) To enable this extension, use "-march=rv{32,64}gc_zacas" CFLAGS. In my development environment, I'm using riscv64-unknown-linux-gnu-gcc (version 15.1.0, commit g1b306039ac4) with the following configure command: `CC=riscv64-unknown-linux-gnu-gcc CFLAGS="-march=rv64gc_zacas" ./configure --prefix=/home/wpcwzy/sysroot-rv64` > i can't review if the instructions have the right semantics, > but the code looks ok, with some comments below. > >> >> Signed-off-by: Pincheng Wang >> --- >> arch/riscv32/atomic_arch.h | 17 +++++++++++++++++ >> arch/riscv64/atomic_arch.h | 30 ++++++++++++++++++++++++++++++ >> 2 files changed, 47 insertions(+) >> >> diff --git a/arch/riscv32/atomic_arch.h b/arch/riscv32/atomic_arch.h >> index 4d418f63..64ef05b7 100644 >> --- a/arch/riscv32/atomic_arch.h >> +++ b/arch/riscv32/atomic_arch.h >> } >> +#ifdef __riscv_zacas > > newline before #ifdef > >> +#else /* Fallback to lr/sc when Zacas is not available */ > ... >> +#endif /* __riscv_zacas */ >> \ No newline at end of file > > newline after endif > > i think ifdef comments are not needed in such a simple file. > Thank you for the formatting suggestions. I'll address these in the next revision. >> +++ b/arch/riscv64/atomic_arch.h >> @@ -4,6 +4,34 @@ static inline void a_barrier() >> __asm__ __volatile__ ("fence rw,rw" : : : "memory"); >> } >> >> +#ifdef __riscv_zacas >> + >> +#define a_cas a_cas >> +static inline int a_cas(volatile int *p, int t, int s) >> +{ >> + int old = t; >> + __asm__ __volatile__ ( >> + "amocas.w.aqrl %0, %2, %1" >> + : "+r"(old), "+A"(*(volatile int *)p) >> + : "r"(s) >> + : "memory"); > > existing cas does not use +A constraint (check git log > why and ensure this is ok). > > the ptr cast should not be needed. (same for rv32) Thanks, I will review the git history and adjust the constraint and cast in the next patch revision. Best regards, Pincheng Wang