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=-1.5 required=5.0 tests=MAILING_LIST_MULTI,PDS_BTC_ID, 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 24611 invoked from network); 13 Mar 2020 14:05:19 -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 14:05:19 -0000 Received: (qmail 11490 invoked by uid 550); 13 Mar 2020 14:05:16 -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 11472 invoked from network); 13 Mar 2020 14:05:15 -0000 Date: Fri, 13 Mar 2020 10:05:03 -0400 From: Rich Felker To: Ruinland ChuanTzu Tsai Cc: musl@lists.openwall.com, wangtc@andestech.com Message-ID: <20200313140503.GM11469@brightrain.aerifal.cx> References: <7D9266CBFB4E9A4B9C7B1D0341567D8601727F45@DGGEMI529-MBX.china.huawei.com> <20200312135715.GK11469@brightrain.aerifal.cx> <202003130543.02D5h9Zk085624@ATCSQR.andestech.com> <20200313060241.GB3971@APC301.andestech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200313060241.GB3971@APC301.andestech.com> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] musl support riscv32 On Fri, Mar 13, 2020 at 02:02:41PM +0800, Ruinland ChuanTzu Tsai wrote: > Hi zhiwei all, > > We (Andes Technology) have been porting Drew and others' work on musl for RV32 to 1.2.0. > For now it can boot a busybox based RV32 Linux successfully and it passed most of the libc-test cases. > Further verification on our inhouse port is undergoing. > > > I think that wrapping atomic handling (e.g. LR/SC pair) is viable yet might need more discussion about the design. > My colleague Simon is also in the CC list, so if zhiwei has interets about customizing such parts. > We might work out together. > > By the way, there are some interesting work trying to add A extension without LR/SC to wimpy softcores. > Such as Princeton's OpenPiton : > https://github.com/PrincetonUniversity/openpiton/commit/3f8ba2600fb36032ddb9510c862e53c5bcf963fc#diff-3199fa5f89bf3b9db625bd88a6a6b8c6 Is there a reason they're not just implementing LR/SC for "wimpy softcores"? As long as you're not doing SMP it admits a trivial implementation, and it's much easier than doing the other A extensions which require support for instructions that can both load and store (which impacts the kind of pipeline architectures you can do, or requires support for microcoded instructions). Rich > 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. > > > > zhiwei > > > > -----邮件原件----- > > 发件人: Rich Felker [mailto:dalias@libc.org] > > 发送时间: 2020年3月12日 21:57 > > 收件人: musl@lists.openwall.com > > 主题: Re: [musl] musl support riscv32 > > > > On Thu, Mar 12, 2020 at 11:09:37AM +0000, chengzhiwei (C) wrote: > > > Hi, all: > > > Recently, we did a survey about musl lib supported by the target of riscv. As we know, musl-riscv64 was released last year, it's a great job: > > > https://git.musl-libc.org/cgit/musl/commit/?id=0a48860c27a8eb291bcc761 > > > 6ea9eb073dc660cab > > > > > > But we want to know when musl will suoport riscv-32 target and be released in the community based on the latest version? > > > From the community, we found that the previous branch version > > > supported 32 bits backend, > > > https://github.com/riscv/riscv-musl/tree/riscv-musl-1.1.18 > > > https://github.com/riscv/riscv-musl/tree/riscv-musl-1.1.20 > > > I guess there are still lots of tests to be done for stability reasons. Next release can support riscv-32 target? > > > > > > Maybe it's not an easy job about atomic operation. If the version support date is uncertain, can you share some solutions to circumvent it? > > > Our team is also considering the possibility of implementing the functionality in C code, could you give us some suggestions? > > > > > > Hope your response！ > > > > The main blocker for riscv32 has been that the kernel has not declared it a stable ABI yet. At the time it was first proposed, there were still problems related to it being a 32-bit arch with no legacy 32-bit time_t syscalls, but that's not an issue now. I'd be happy to look at an updated riscv32 port now (ideally based on what's upstram in musl for riscv64, converted to 32-bit, rather than the old proposal, since lots of bugs were fixed after it was merged) and hopefully convince Linus/kernel ppl to consider it stabilized on the basis that there's a libc ready to use it. > > > > Rich