* Re: [RFC PATCH 1/1] RISC-V: Add privileged extensions without instructions/CSRs
@ 2022-09-23 1:30 jiawei
0 siblings, 0 replies; 5+ messages in thread
From: jiawei @ 2022-09-23 1:30 UTC (permalink / raw)
To: Tsukasa OI; +Cc: binutils, Nelson Chu
[-- Attachment #1: Type: text/plain, Size: 176 bytes --]
I had sent a implement patch for ‘smepem’ last year；
https://sourceware.org/pipermail/binutils/2021-December/119027.html
I will check and make it up to date 😊
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 1/1] RISC-V: Add privileged extensions without instructions/CSRs
2022-09-22 9:44 ` Tsukasa OI
@ 2022-09-30 15:44 ` Tsukasa OI
0 siblings, 0 replies; 5+ messages in thread
From: Tsukasa OI @ 2022-09-30 15:44 UTC (permalink / raw)
To: binutils
On 2022/09/22 18:44, Tsukasa OI via Binutils wrote:
> On 2022/09/22 17:48, Nelson Chu wrote:
>> On Thu, Sep 22, 2022 at 3:59 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote:
>>>
>>> Currently, GNU Binutils does not support following privileged extensions:
>>>
>>> - 'Smepmp'
>>> - 'Svnapot'
>>> - 'Svpbmt'
>>>
>>> as they do not provide new CSRs or new instructions ('Smepmp' extends the
>>> privileged architecture CSRs but does not define the CSR itself). However,
>>> adding them might be useful as we no longer have to "filter" ISA strings
>>> just for toolchains (if full ISA string is given by a vendor, we can
>>> straightly use it).
>>
>> OKay.
>>
>> Nelson
>
> Understood. I'm going to push this patch in a week if there's no other
> comments. But until then, I'll wait for other opinions.
>
> Thanks,
> Tsukasa
Committed since there's no objections here.
Thanks,
Tsukasa
>
>>
>>> And there's a fact that supports this theory: there's already an
>>> (unprivileged) extension which does not provide CSRs or instructions (but
>>> only an architectural guarantee): 'Zkt' (constant timing guarantee for
>>> certain subset of RISC-V instructions).
>>>
>>> This simple patchset simply adds three privileged extensions listed above.
>>>
>>> bfd/ChangeLog:
>>>
>>> * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smepmp',
>>> 'Svnapot' and 'Svpbmt' extensions.
>>> ---
>>> bfd/elfxx-riscv.c | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
>>> index 7eda177bd6e..bbc30c9afc2 100644
>>> --- a/bfd/elfxx-riscv.c
>>> +++ b/bfd/elfxx-riscv.c
>>> @@ -1210,10 +1210,13 @@ static struct riscv_supported_ext riscv_supported_std_z_ext[] =
>>>
>>> static struct riscv_supported_ext riscv_supported_std_s_ext[] =
>>> {
>>> + {"smepmp", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>>> {"smstateen", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>>> {"sscofpmf", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>>> {"sstc", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>>> {"svinval", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>>> + {"svnapot", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>>> + {"svpbmt", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>>> {NULL, 0, 0, 0, 0}
>>> };
>>>
>>> --
>>> 2.34.1
>>>
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 1/1] RISC-V: Add privileged extensions without instructions/CSRs
2022-09-22 8:48 ` Nelson Chu
@ 2022-09-22 9:44 ` Tsukasa OI
2022-09-30 15:44 ` Tsukasa OI
0 siblings, 1 reply; 5+ messages in thread
From: Tsukasa OI @ 2022-09-22 9:44 UTC (permalink / raw)
To: Nelson Chu; +Cc: Kito Cheng, Palmer Dabbelt, Andrew Waterman, binutils
On 2022/09/22 17:48, Nelson Chu wrote:
> On Thu, Sep 22, 2022 at 3:59 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote:
>>
>> Currently, GNU Binutils does not support following privileged extensions:
>>
>> - 'Smepmp'
>> - 'Svnapot'
>> - 'Svpbmt'
>>
>> as they do not provide new CSRs or new instructions ('Smepmp' extends the
>> privileged architecture CSRs but does not define the CSR itself). However,
>> adding them might be useful as we no longer have to "filter" ISA strings
>> just for toolchains (if full ISA string is given by a vendor, we can
>> straightly use it).
>
> OKay.
>
> Nelson
Understood. I'm going to push this patch in a week if there's no other
comments. But until then, I'll wait for other opinions.
Thanks,
Tsukasa
>
>> And there's a fact that supports this theory: there's already an
>> (unprivileged) extension which does not provide CSRs or instructions (but
>> only an architectural guarantee): 'Zkt' (constant timing guarantee for
>> certain subset of RISC-V instructions).
>>
>> This simple patchset simply adds three privileged extensions listed above.
>>
>> bfd/ChangeLog:
>>
>> * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smepmp',
>> 'Svnapot' and 'Svpbmt' extensions.
>> ---
>> bfd/elfxx-riscv.c | 3 +++
>> 1 file changed, 3 insertions(+)
>>
>> diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
>> index 7eda177bd6e..bbc30c9afc2 100644
>> --- a/bfd/elfxx-riscv.c
>> +++ b/bfd/elfxx-riscv.c
>> @@ -1210,10 +1210,13 @@ static struct riscv_supported_ext riscv_supported_std_z_ext[] =
>>
>> static struct riscv_supported_ext riscv_supported_std_s_ext[] =
>> {
>> + {"smepmp", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"smstateen", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"sscofpmf", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"sstc", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {"svinval", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"svnapot", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> + {"svpbmt", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
>> {NULL, 0, 0, 0, 0}
>> };
>>
>> --
>> 2.34.1
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFC PATCH 1/1] RISC-V: Add privileged extensions without instructions/CSRs
2022-09-22 7:58 ` [RFC PATCH 1/1] " Tsukasa OI
@ 2022-09-22 8:48 ` Nelson Chu
2022-09-22 9:44 ` Tsukasa OI
0 siblings, 1 reply; 5+ messages in thread
From: Nelson Chu @ 2022-09-22 8:48 UTC (permalink / raw)
To: Tsukasa OI; +Cc: Kito Cheng, Palmer Dabbelt, Andrew Waterman, binutils
On Thu, Sep 22, 2022 at 3:59 PM Tsukasa OI <research_trasio@irq.a4lg.com> wrote:
>
> Currently, GNU Binutils does not support following privileged extensions:
>
> - 'Smepmp'
> - 'Svnapot'
> - 'Svpbmt'
>
> as they do not provide new CSRs or new instructions ('Smepmp' extends the
> privileged architecture CSRs but does not define the CSR itself). However,
> adding them might be useful as we no longer have to "filter" ISA strings
> just for toolchains (if full ISA string is given by a vendor, we can
> straightly use it).
OKay.
Nelson
> And there's a fact that supports this theory: there's already an
> (unprivileged) extension which does not provide CSRs or instructions (but
> only an architectural guarantee): 'Zkt' (constant timing guarantee for
> certain subset of RISC-V instructions).
>
> This simple patchset simply adds three privileged extensions listed above.
>
> bfd/ChangeLog:
>
> * elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smepmp',
> 'Svnapot' and 'Svpbmt' extensions.
> ---
> bfd/elfxx-riscv.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
> index 7eda177bd6e..bbc30c9afc2 100644
> --- a/bfd/elfxx-riscv.c
> +++ b/bfd/elfxx-riscv.c
> @@ -1210,10 +1210,13 @@ static struct riscv_supported_ext riscv_supported_std_z_ext[] =
>
> static struct riscv_supported_ext riscv_supported_std_s_ext[] =
> {
> + {"smepmp", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
> {"smstateen", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
> {"sscofpmf", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
> {"sstc", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
> {"svinval", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
> + {"svnapot", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
> + {"svpbmt", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
> {NULL, 0, 0, 0, 0}
> };
>
> --
> 2.34.1
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [RFC PATCH 1/1] RISC-V: Add privileged extensions without instructions/CSRs
2022-09-22 7:58 [RFC PATCH 0/1] " Tsukasa OI
@ 2022-09-22 7:58 ` Tsukasa OI
2022-09-22 8:48 ` Nelson Chu
0 siblings, 1 reply; 5+ messages in thread
From: Tsukasa OI @ 2022-09-22 7:58 UTC (permalink / raw)
To: Tsukasa OI, Nelson Chu, Kito Cheng, Palmer Dabbelt, Andrew Waterman
Cc: binutils
Currently, GNU Binutils does not support following privileged extensions:
- 'Smepmp'
- 'Svnapot'
- 'Svpbmt'
as they do not provide new CSRs or new instructions ('Smepmp' extends the
privileged architecture CSRs but does not define the CSR itself). However,
adding them might be useful as we no longer have to "filter" ISA strings
just for toolchains (if full ISA string is given by a vendor, we can
straightly use it).
And there's a fact that supports this theory: there's already an
(unprivileged) extension which does not provide CSRs or instructions (but
only an architectural guarantee): 'Zkt' (constant timing guarantee for
certain subset of RISC-V instructions).
This simple patchset simply adds three privileged extensions listed above.
bfd/ChangeLog:
* elfxx-riscv.c (riscv_supported_std_s_ext): Add 'Smepmp',
'Svnapot' and 'Svpbmt' extensions.
---
bfd/elfxx-riscv.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/bfd/elfxx-riscv.c b/bfd/elfxx-riscv.c
index 7eda177bd6e..bbc30c9afc2 100644
--- a/bfd/elfxx-riscv.c
+++ b/bfd/elfxx-riscv.c
@@ -1210,10 +1210,13 @@ static struct riscv_supported_ext riscv_supported_std_z_ext[] =
static struct riscv_supported_ext riscv_supported_std_s_ext[] =
{
+ {"smepmp", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
{"smstateen", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
{"sscofpmf", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
{"sstc", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
{"svinval", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
+ {"svnapot", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
+ {"svpbmt", ISA_SPEC_CLASS_DRAFT, 1, 0, 0 },
{NULL, 0, 0, 0, 0}
};
--
2.34.1
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-09-30 15:44 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-23 1:30 [RFC PATCH 1/1] RISC-V: Add privileged extensions without instructions/CSRs jiawei
-- strict thread matches above, loose matches on Subject: below --
2022-09-22 7:58 [RFC PATCH 0/1] " Tsukasa OI
2022-09-22 7:58 ` [RFC PATCH 1/1] " Tsukasa OI
2022-09-22 8:48 ` Nelson Chu
2022-09-22 9:44 ` Tsukasa OI
2022-09-30 15:44 ` Tsukasa OI
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 read-only IMAP folder(s) and NNTP newsgroup(s).