OpenE2K/qemu-e2k
13
4
Fork 0
Code Issues 4 Pull Requests Projects 2 Releases Activity

target/arm: Add isar_feature_any_fp16 and document naming/usage conventions

Browse Source 
Our current usage of the isar_feature feature tests almost always
uses an _aa32_ test when the code path is known to be AArch32
specific and an _aa64_ test when the code path is known to be
AArch64 specific. There is just one exception: in the vfp_set_fpscr
helper we check aa64_fp16 to determine whether the FZ16 bit in
the FP(S)CR exists, but this code is also used for AArch32.
There are other places in future where we're likely to want
a general "does this feature exist for either AArch32 or
AArch64" check (typically where architecturally the feature exists
for both CPU states if it exists at all, but the CPU might be
AArch32-only or AArch64-only, and so only have one set of ID
registers).

Introduce a new category of isar_feature_* functions:
isar_feature_any_foo() should be tested when what we want to
know is "does this feature exist for either AArch32 or AArch64",
and always returns the logical OR of isar_feature_aa32_foo()
and isar_feature_aa64_foo().

Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Message-id: 20200214175116.9164-4-peter.maydell@linaro.org
This commit is contained in:
Peter Maydell 2020-02-14 17:50:58 +00:00
parent f8af1143ef
commit 6e61f8391c
2 changed files with 19 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
target/arm/cpu.h
View File

@ -3328,7 +3328,16 @@ extern const uint64_t pred_esz_masks[4];
* Naming convention for isar_feature functions:
* Functions which test 32-bit ID registers should have _aa32_ in
* their name. Functions which test 64-bit ID registers should have
* _aa64_ in their name.
* _aa64_ in their name. These must only be used in code where we
* know for certain that the CPU has AArch32 or AArch64 respectively
* or where the correct answer for a CPU which doesn't implement that
* CPU state is "false" (eg when generating A32 or A64 code, if adding
* system registers that are specific to that CPU state, for "should
* we let this system register bit be set" tests where the 32-bit
* flavour of the register doesn't have the bit, and so on).
* Functions which simply ask "does this feature exist at all" have
* _any_ in their name, and always return the logical OR of the _aa64_
* and the _aa32_ function.
*/
/*
@ -3660,6 +3669,14 @@ static inline bool isar_feature_aa64_bti(const ARMISARegisters *id)
return FIELD_EX64(id->id_aa64pfr1, ID_AA64PFR1, BT) != 0;
}
/*
* Feature tests for "does this exist in either 32-bit or 64-bit?"
*/
static inline bool isar_feature_any_fp16(const ARMISARegisters *id)
{
return isar_feature_aa64_fp16(id) || isar_feature_aa32_fp16_arith(id);
}
/*
* Forward to the above feature tests given an ARMCPU pointer.
*/

2
target/arm/vfp_helper.c
View File

@ -185,7 +185,7 @@ uint32_t vfp_get_fpscr(CPUARMState *env)
void HELPER(vfp_set_fpscr)(CPUARMState *env, uint32_t val)
{
/* When ARMv8.2-FP16 is not supported, FZ16 is RES0. */
if (!cpu_isar_feature(aa64_fp16, env_archcpu(env))) {
if (!cpu_isar_feature(any_fp16, env_archcpu(env))) {
val &= ~FPCR_FZ16;
}