[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Fri, 13 Mar 2020 10:05:03 -0400
From: Rich Felker <dalias@...c.org>
To: Ruinland ChuanTzu Tsai <ruinland@...estech.com>
Cc: musl@...ts.openwall.com, wangtc@...estech.com
Subject: Re: 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@...c.org]
> > 发送时间: 2020年3月12日 21:57
> > 收件人: musl@...ts.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
