[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RFC PATCH v1 2/2] Enable custom instruction suport for Andes A25 an

From: Alex Bennée
Subject: Re: [RFC PATCH v1 2/2] Enable custom instruction suport for Andes A25 and AX25 CPU model
Date: Fri, 22 Oct 2021 12:52:18 +0100
User-agent: mu4e 1.7.0; emacs 28.0.60

Ruinland ChuanTzu Tsai <ruinland@andestech.com> writes:

> On Thu, Oct 21, 2021 at 12:17:47PM -0700, Richard Henderson wrote:
>> On 10/21/21 8:11 AM, Ruinland Chuan-Tzu Tsai wrote:
>> > In this patch, we demonstrate how Andes Performance Extension(c) insn :
>> > bfos and bfoz could be used with Andes CoDense : exec.it.
>> > 
>> > +static int andes_v5_gen_codense_exec_it(CPURISCVState *env, DisasContext 
>> > *ctx, arg_execit *a)
>> > +{
>> > +    uint32_t insn;
>> > +    uint32_t imm_ex10 = a->imm_codense;
>> > +    target_ulong uitb_val = 0;
>> > +    riscv_csrrw(env, 0x800, &uitb_val, 0, 0);
>> This won't work -- you can't access env during translation.  So all this
>> faff around passing env through HartState is for naught.
> Sorry, please elaborate me a little bit more.

When dealing with translation you need to separate the translation phase
from the execution phase. CPUEnv is the current run time state of the
vCPU so the value that might be stored in it when you do translation
could very well be different when the translation runs (or runs again).

The correct way to deal with this is by the use of translation flags. If
for example the translation is only valid for a particular execution
state you represent that in a translation flag which you compute in
cpu_get_tb_cpu_state. This ensures that the translated block will only
get looked up when you are in that translation state - if it's not you
will generate a new block for the current state. See the section:


of the developer guide.

Alex Bennée

reply via email to

[Prev in Thread] Current Thread [Next in Thread]