[Top][All Lists]

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

Re: [PATCH 0/5] handle M-profile in fp16_arith isar_feature test

From: Richard Henderson
Subject: Re: [PATCH 0/5] handle M-profile in fp16_arith isar_feature test
Date: Fri, 11 Sep 2020 12:40:16 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0

On 9/10/20 10:38 AM, Peter Maydell wrote:
> This series leaves us with two different ways to check for "is this
> M-profile?" -- the old ARM_FEATURE_M bit, and also the new
> isar_feature_aa32_mprofile() test.  We could in theory convert the
> users of ARM_FEATURE_M, but I haven't, because there are a lot of
> callsites, and it can't be done automatically:
>  * arm_feature() takes the CPUARMState* whereas cpu_isar_feature()
>    takes the ARMCPU*, so each callsite needs manual attention to
>    identify whether it already has a 'cpu' local variable and
>    add one if it doesn't
>  * awkwardly, the KVM-on-AArch64-only host case does not zero
>    out these ID register fields (see the comment in kvm64.c
>    kvm_arm_get_host_cpu_features()), so calling the
>    isar_feature function is only valid if we already know that
>    this CPU is AArch32 -- this would need manually checking
>    at all callsites. (Unless we wanted to change our minds about
>    leaving UNKNOWN values in the ID register fields.)

That is why I had suggested moving env->features to cpu->isar.features, so that
it would be nearby.

Which would give us

static inline bool isar_feature(const ARMISARegisters *id,
                                int feature)
    return extract64(id->features, feature, 1);

static inline bool arm_feature(CPUARMState *env, int feature)
    return isar_feature(&env_archcpu(env)->isar, feature);

But what you have at present solves the current problem, where we know we're in
aa32 mode in translate.c.


reply via email to

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