[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/2] target/arm: Disable VFPv4-D32 when NEON is not available
From: |
Peter Maydell |
Subject: |
Re: [PATCH 1/2] target/arm: Disable VFPv4-D32 when NEON is not available |
Date: |
Thu, 29 Sep 2022 12:48:20 +0100 |
On Thu, 29 Sept 2022 at 08:20, Cédric Le Goater <clg@kaod.org> wrote:
>
> On 9/29/22 01:00, Joel Stanley wrote:
> > On Wed, 28 Sept 2022 at 16:47, Cédric Le Goater <clg@kaod.org> wrote:
> >> @@ -1684,6 +1684,10 @@ static void arm_cpu_realizefn(DeviceState *dev,
> >> Error **errp)
> >> cpu->isar.id_isar6 = u;
> >>
> >> if (!arm_feature(env, ARM_FEATURE_M)) {
> >
> > Can you explain why the test is put behind the !ARM_FEATURE_M check?
>
> Do you mean the setting of MVFR0 ?
>
> because it was close to the code clearing the SIMD bits (NEON)
> of MVFR1 and it seemed more in sync with the specs :
>
> "When FPU option is selected without NEON, the FPU is VFPv4-D16 and
> uses 16 double-precision registers. When the FPU is implemented with
> NEON, the FPU is VFPv4-D32 and uses 32 double-precision registers.
> This register bank is shared with NEON."
>
> (That said, M processors don't have NEON, so this part of the code
> should never be reached )
They don't have Neon, but that means that cpu->has_neon is
false, so this part of the code *will* be reached. The reason
this sub-part of the "disable Neon" handling is inside
a not-M check is because M-profile has a different assignment
for some of the MVFR1 fields (check the comments in the FIELD
definitions in cpu.h), and zeroing things out based on the
A-profile meanings would be wrong.
thanks
-- PMM
[PATCH 2/2] ast2600: Drop NEON from the CPU features, Cédric Le Goater, 2022/09/28