From: LIU Zhiwei <zhiwei_liu@c-sky.com>
To: Jim Wilson <jimw@sifive.com>,
alistair23@gmail.com, richard.henderson@linaro.org,
chihmin.chao@sifive.com, palmer@dabbelt.com
Cc: wenmeng_zhang@c-sky.com, qemu-riscv@nongnu.org,
qemu-devel@nongnu.org, wxy194768@alibaba-inc.com
Subject: Re: [PATCH v3 3/4] RISC-V: support vector extension csr
Date: Tue, 7 Jan 2020 09:34:17 +0800 [thread overview]
Message-ID: <be35d76a-0452-5243-d282-1c60aaa06bfc@c-sky.com> (raw)
In-Reply-To: <ec0fe07a-ae3d-6502-18fa-d89547d918aa@sifive.com>
On 2020/1/7 6:00, Jim Wilson wrote:
> On 1/2/20 7:33 PM, LIU Zhiwei wrote:
>> Until v0.7.1 specification, vector status is still not defined for
>> mstatus.
>
> The v0.8 spec does define a VS bit in mstatus.
>
Yes, I will also support v0.8 spec after the v0.7.1 spec.
>> @@ -107,11 +112,6 @@ static int pmp(CPURISCVState *env, int csrno)
>> /* User Floating-Point CSRs */
>> static int read_fflags(CPURISCVState *env, int csrno, target_ulong
>> *val)
>> {
>> -#if !defined(CONFIG_USER_ONLY)
>> - if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
>> - return -1;
>> - }
>> -#endif
>> *val = riscv_cpu_get_fflags(env);
>> return 0;
>> }
>
> This allows reads of fflags when it doesn't exist, and hence does not
> make much sense. Instead of removing the code, you should add a check
> for the vector extension, since the vector extension requires that
> fcsr exist even if the base architecture doesn't include FP support.
> Ideally this should use the VS bit, but if you don't have it then you
> can just check to see if the vector extension was enabled as a command
> line option.
>
I' sorry that there is some ambiguous here. The reason to remove these
code is that they are redundant, and has nothing to do with the vector
extension. I just delete them by hand.
As you can see, all float csr has a predicate function.
static int fs(CPURISCVState *env, int csrno)
{
#if !defined(CONFIG_USER_ONLY)
if (!env->debugger && !(env->mstatus & MSTATUS_FS)) {
return -1;
}
#endif
return 0;
}
The read or write function must be called after the predicate return 0.
So no need to check (!env->debugger && !(env->mstatus & MSTATUS_FS) again.
> While the vector spec says that fcsr must exist, it doesn't specify
> that the FP fields in fcsr are necessarily readable or writable when
> there is no FP. It also doesn't specify whether the other FP related
> shadows of fcsr exist, like fflags. This appears to have been left
> unspecified. I don't think that you should be making fflags reads and
> writes work for a target with vector but without float. I think it
> would make more sense to have fcsr behave 3 different ways depending
> on whether we have only F, only V, or both F and V. And then we can
> support reads and writes of only the valid fields.
>
Thanks. Maybe I should just only loose the check condition for fcsr.
Best Regards,
Zhiwei
> Jim
next prev parent reply other threads:[~2020-01-07 1:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-01-03 3:33 [PATCH v3 0/4] RISC-V: support vector extension part 1 LIU Zhiwei
2020-01-03 3:33 ` [PATCH v3 1/4] RISC-V: add vector extension field in CPURISCVState LIU Zhiwei
2020-01-03 23:05 ` Richard Henderson
2020-01-03 3:33 ` [PATCH v3 2/4] RISC-V: configure and turn on vector extension from command line LIU Zhiwei
2020-01-03 23:08 ` Richard Henderson
2020-01-06 21:48 ` Jim Wilson
2020-01-07 1:42 ` LIU Zhiwei
2020-01-03 3:33 ` [PATCH v3 3/4] RISC-V: support vector extension csr LIU Zhiwei
2020-01-03 23:14 ` Richard Henderson
2020-01-06 22:00 ` Jim Wilson
2020-01-07 1:34 ` LIU Zhiwei [this message]
2020-01-03 3:33 ` [PATCH v3 4/4] RISC-V: add vector extension configure instruction LIU Zhiwei
2020-01-03 23:41 ` Richard Henderson
2020-01-07 2:11 ` LIU Zhiwei
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=be35d76a-0452-5243-d282-1c60aaa06bfc@c-sky.com \
--to=zhiwei_liu@c-sky.com \
--cc=alistair23@gmail.com \
--cc=chihmin.chao@sifive.com \
--cc=jimw@sifive.com \
--cc=palmer@dabbelt.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-riscv@nongnu.org \
--cc=richard.henderson@linaro.org \
--cc=wenmeng_zhang@c-sky.com \
--cc=wxy194768@alibaba-inc.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.
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).