[prev in list] [next in list] [prev in thread] [next in thread] 

List:       binutils
Subject:    Re: [PATCH 0/3] RISC-V: Prepare Privileged Architecture 1.12
From:       Nelson Chu <nelson.chu () sifive ! com>
Date:       2021-12-31 1:45:42
Message-ID: CAJYME4FSc3jOnQuHWhChykqw9WkX7Xu=FJL3Bysb9EUxo_CZSg () mail ! gmail ! com
[Download RAW message or body]

On Fri, Dec 24, 2021 at 5:21 PM Nelson Chu <nelson.chu@sifive.com> wrote:
> Besides, there are some TODOs you or others may interesting,
>
> * In the csr-version-xxx.l, I think these warnings have a lot of room
> for improvement.  For now, I just report "invalid CSR `xxx' for the
> current ISA", but it would be great if we can report more details to
> users.  For example, "invalid CSR `xxx', need to enable xxx extension"
> or "invalid rv32-only CSR `xxx'".   Besides, we probably will have to
> check multiple extensions for the CSR, like CSR_CLASS_H_AND_SVINVAL,
> so the error messages may be more complicated.

I have created a bugzilla for this,
https://sourceware.org/bugzilla/show_bug.cgi?id=28733.  I have heard
that Palmer has got a new developer who's interested in the related
works - improve the error/warning reporting in GNU assembler.  We
could talk more details in the bugzilla, thanks.

Nelson

> * For now we are using PRIV_SPEC_CLASS_XXX in the DECLARE_CSR, to
> describe when the csr was(is) defined, and when the csr was(is)
> dropped.  But according to the link,
> https://wiki.riscv.org/display/TECH/Recently+Ratified+Extensions, I
> see that the extensions Sm1-12 and Ss1-12 are ratified..., and we will
> also have an extension name for hypersior in the arch string.
> Therefore, I suppose all csrs will be controlled by the extension
> versions, rather than the privileged spec versions, so we will need to
> rewrite the whole current code in the future.
>
> BTW, the Sm1-12 and Ss1-12 extension names look weird to me, since I
> expect they should be Sm and Ss, with the different versions 1p12 or
> <major>p<minor>p<revision> in the arch string.  Anyway, this is a
> different issue in fact.
>
> Thanks
> Nelson
[prev in list] [next in list] [prev in thread] [next in thread]