mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Ruinland ChuanTzu Tsai <ruinland@andestech.com>
Cc: musl@lists.openwall.com, wangtc@andestech.com
Subject: Re: [musl]  musl support riscv32
Date: Fri, 13 Mar 2020 10:05:03 -0400	[thread overview]
Message-ID: <20200313140503.GM11469@brightrain.aerifal.cx> (raw)
In-Reply-To: <20200313060241.GB3971@APC301.andestech.com>

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

      reply	other threads:[~2020-03-13 14:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-12 11:09 chengzhiwei (C)
2020-03-12 13:57 ` Rich Felker
2020-03-13  2:05   ` [musl] 答复: " chengzhiwei (C)
2020-03-13  2:13     ` Rich Felker
     [not found]   ` <202003130543.02D5h9Zk085624@ATCSQR.andestech.com>
2020-03-13  6:02     ` Ruinland ChuanTzu Tsai
2020-03-13 14:05       ` Rich Felker [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200313140503.GM11469@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    --cc=ruinland@andestech.com \
    --cc=wangtc@andestech.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).