qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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



  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).