[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH 1/3] target/arm: Convert Neon 3-same-fp size field to MO_* in
From: |
Richard Henderson |
Subject: |
Re: [PATCH 1/3] target/arm: Convert Neon 3-same-fp size field to MO_* in decode |
Date: |
Thu, 3 Sep 2020 09:25:17 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 |
On 9/3/20 6:32 AM, Peter Maydell wrote:
> In the Neon instructions, some instruction formats have a 2-bit size
> field which corresponds exactly to QEMU's MO_8/16/32/64. However the
> floating-point insns in the 3-same group have a 1-bit size field
> which is "0 for 32-bit float and 1 for 16-bit float". Currently we
> pass these values directly through to trans_ functions, which means
> that when reading a particular trans_ function you need to know if
> that insn uses a 2-bit size or a 1-bit size.
>
> Move the handling of the 1-bit size to the decodetree file, so that
> all these insns consistently pass a size to the trans_ function which
> is an MO_8/16/32/64 value.
>
> In this commit we switch over the insns using the 3same_fp and
> 3same_fp_q0 formats.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> ---
> I wanted to call the field %3same_fp_size, but decodetree
> doesn't seem to allow a field starting with a digit, even
> though it does allow a format that starts with a digit.
> So it's %fp_3same_size...
Odd. All of the names get prefixed, so we don't have a problem of a digit
beginning a C identifier... I can look at fixing this if you want.
r~